Log in
Register
Cyber Forum
More options
Toggle width
Share this page
Share this page
Share
Share
Cyber Forum
Log in
Register
More options
Toggle width
Share this page
Share this page
Share
Share
Menu
Install the app
Install
Home
CyberWeekly Podcast
Breaking News! Podcast
Cyber Risk Rating
Forums
New posts
Forum list
Trending
Leaderboards
News Feeds
Resources
Latest reviews
Sophos X-Ops Intelix
Threat Reports
Members
Current visitors
My.CompTIA
Help Documents
Preference Center
Forums
Security
Active Exploits Discussion/Recommendations
Log4j Vulnerability Information
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="Jonathan Braley" data-source="post: 2512" data-attributes="member: 77"><p>Ian came across this:</p><p></p><p>NCC has a good write-up on how to mitigate beyond patches.</p><p></p><p>[URL unfurl="true"]https://research.nccgroup.com/2021/12/12/log4j-jndi-be-gone-a-simple-mitigation-for-cve-2021-44228/[/URL]</p><p></p><p>"None of these solutions are ideal because they all presume that everyone has a 100% handle on their dependency chains and that you won’t end up with a mix of log4j versions strewn across the subcomponents of apps segmented across multiple classloaders (looking at you, WAR files). The reality is that the node_modules-style of dependency embedding is not completely alien to the Java ecosystem (and Java has a host of left-pad type issues due to how its build systems resolve dependencies across multiple repositories). In addition to this, many apps and proprietary libraries and app servers possibly vendor-in log4j in weird ways that end up preferring their own versions over any shared version that might actually be updated by your ops team. All told, tracking down and updating every instance of a library like this in your application stack is a nontrivial process and potentially error prone as any one rogue log4j copy can potentially keep a service vulnerable." (NCC Group)</p><p></p><h2>A tool to mitigate Log4Shell by disabling log4j JNDI</h2><p>To try to make the situation a little bit more manageable in the meantime, we are releasing <a href="https://github.com/nccgroup/log4j-jndi-be-gone" target="_blank">log4j-jndi-be-gone</a>, a dead simple <a href="https://docs.oracle.com/en/java/javase/16/docs/api/java.instrument/java/lang/instrument/package-summary.html" target="_blank">Java agent</a> that disables the log4j JNDI handler outright. log4j-jndi-be-gone uses the <a href="https://github.com/raphw/byte-buddy/" target="_blank">Byte Buddy</a> bytecode manipulation library to modify the at-issue log4j class’s method code and short circuit the JNDI interpolation handler. It works by effectively hooking the at-issue JndiLookup class’ lookup() method that Log4Shell exploits to load remote code, and forces it to stop early without actually loading the Log4Shell payload URL. It also supports Java 6 through 17, covering older versions of log4j that support Java 6 (2.0-2.3) and 7 (2.4-2.12.1), and works on read-only filesystems (once installed or mounted) such as in read-only containers.</p></blockquote><p></p>
[QUOTE="Jonathan Braley, post: 2512, member: 77"] Ian came across this: NCC has a good write-up on how to mitigate beyond patches. [URL unfurl="true"]https://research.nccgroup.com/2021/12/12/log4j-jndi-be-gone-a-simple-mitigation-for-cve-2021-44228/[/URL] "None of these solutions are ideal because they all presume that everyone has a 100% handle on their dependency chains and that you won’t end up with a mix of log4j versions strewn across the subcomponents of apps segmented across multiple classloaders (looking at you, WAR files). The reality is that the node_modules-style of dependency embedding is not completely alien to the Java ecosystem (and Java has a host of left-pad type issues due to how its build systems resolve dependencies across multiple repositories). In addition to this, many apps and proprietary libraries and app servers possibly vendor-in log4j in weird ways that end up preferring their own versions over any shared version that might actually be updated by your ops team. All told, tracking down and updating every instance of a library like this in your application stack is a nontrivial process and potentially error prone as any one rogue log4j copy can potentially keep a service vulnerable." (NCC Group) [HEADING=1]A tool to mitigate Log4Shell by disabling log4j JNDI[/HEADING] To try to make the situation a little bit more manageable in the meantime, we are releasing [URL='https://github.com/nccgroup/log4j-jndi-be-gone']log4j-jndi-be-gone[/URL], a dead simple [URL='https://docs.oracle.com/en/java/javase/16/docs/api/java.instrument/java/lang/instrument/package-summary.html']Java agent[/URL] that disables the log4j JNDI handler outright. log4j-jndi-be-gone uses the [URL='https://github.com/raphw/byte-buddy/']Byte Buddy[/URL] bytecode manipulation library to modify the at-issue log4j class’s method code and short circuit the JNDI interpolation handler. It works by effectively hooking the at-issue JndiLookup class’ lookup() method that Log4Shell exploits to load remote code, and forces it to stop early without actually loading the Log4Shell payload URL. It also supports Java 6 through 17, covering older versions of log4j that support Java 6 (2.0-2.3) and 7 (2.4-2.12.1), and works on read-only filesystems (once installed or mounted) such as in read-only containers. [/QUOTE]
Name
Verification
Post reply
Forums
Security
Active Exploits Discussion/Recommendations
Log4j Vulnerability Information
Top
Bottom
Home
Forums
Threat Reports
My.CompTIA
Menu