log4j
MLS
Seth Tisue
Aaron Andre Brandes
Hi
The link provided by Seth is the best source of information. I will summarize a few of the points.
I would also like to note that log4j will not be used in the next release of NetLogo.
I don’t think you can simply drop in a different version of log4j.
The use of log4j by NetLogo does not open the user to the recent major vulnerabilities for a number of reasons.
- The logging feature is what uses log4j, so if you don't enable that no messages will be logged. It is not enabled by default. If you need to run HubNet models, you can do so without logging and there should be no risk (even with the version outside the range).
- NetLogo uses a version of log4j outside the affected version ranges. From the log4j post on the Apache site, "Log4j 1.x mitigation: Log4j 1.x is not impacted by this vulnerability." NetLogo uses version 1.2.17.
- NetLogo does not run a server component by default that would expose log4j to input from remote users. There is no way for someone to send the specially crafted message to NetLogo across the network if you just run normal NetLogo or NetLogo 3D models. The HubNet feature does have a server component, but it only runs when special HubNet models are used, so you'll know if you're doing that.
- Log4j 1.x mitigation: Log4j 1.x does not have Lookups so the risk is lower. Applications using Log4j 1.x are only vulnerable to this attack when they use JNDI in their configuration. A separate CVE (CVE-2021-4104) has been filed for this vulnerability. To mitigate: audit your logging configuration to ensure it has no JMSAppender configured. Log4j 1.x configurations without JMSAppender are not impacted by this vulnerability.
- Log4j 1.x mitigation: Log4j 1.x does not have Lookups so the risk is lower. Applications using Log4j 1.x are only vulnerable to this attack when they use JNDI in their configuration. A separate CVE (CVE-2021-4104) has been filed for this vulnerability. To mitigate: audit your logging configuration to ensure it has no JMSAppender configured. Log4j 1.x configurations without JMSAppender are not impacted by this vulnerability.
The vid extension does make use of a more recent version of log4j. This should still not cause a security risk. However you can delete the app\extensions\.bundled\vid\ folder or just remove those log4j jar files from it. It'll stop the vid extension from working, but the rest of NetLogo should be fine
It is also easy to remove this extension from within NetLogo. In NetLogo click on the Tools -> Extensions menu item. Then scroll to the Vid extension (or type Vid in the search bar) and click on the Vid entry. There will be an option in the right hand column to uninstall the extensions.
Please let us know if you have any further questions.
Aaron
--
Aaron Brandes, Software Developer
Center for Connected Learning and Computer-Based Modeling
From: <netlog...@googlegroups.com> on behalf of Seth Tisue <se...@tisue.net>
Date: Saturday, June 25, 2022 at 6:59 PM
To: netlogo-devel <netlog...@googlegroups.com>
Subject: [netlogo-devel] Re: log4j
see discussion at https://github.com/NetLogo/NetLogo/issues/2001
--
You received this message because you are subscribed to the Google Groups "netlogo-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
netlogo-deve...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/netlogo-devel/fee861ed-d904-4895-9b14-eb60375c02edn%40googlegroups.com.