Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Log4j RCE Found

lunasec.io

Post reply on HN
Print view View original

521–530 of 531 posts

Re: Log4j RCE Found

#521

Post by adambatkin »

jcims wrote: post #74

Does anyone in here know what url schemes are valid for JNDI and/or this bug in particular? The example is LDAP but is that the only one JNDI supports? Would HTTPS or even data urls work?

Out of the box (at least on my text 1.8 JVM): corbaname, dns, iiop, iiopname, ldap, ldaps, rmi

For full details of how this works, use a vulnerable log4j version, log a simple (bad) lookup, and step through with a debugger for a while.

Sources:

  - https://github.com/JetBrains/jdk8u_jdk/blob/master/src/share/classes/com/sun/naming/internal/ResourceManager.java#L422
  - https://github.com/JetBrains/jdk8u_jdk/blob/master/src/share/classes/javax/naming/spi/NamingManager.java#L558
  - https://github.com/JetBrains/jdk8u_jdk/tree/master/src/share/classes/com/sun/jndi/url
By default the class will be named "com.sun.jndi.url..URLContextFactory"

So for example, if your schema, the class will be "com.sun.jndi.url.ldap.ldapURLContextFactory".

But also note that many of these schemes can return referrals/redirects to other protocols.

Re: Log4j RCE Found

#522

Post by markhahn »

LOG4J2-2109 wrote: post #159
nightpool wrote: post #108

Earlier quoted context omitted.

Note that the formatMsgNoLookups workaround only applies to recent versions of the log4j library, while it's still unclear how far back this bug may stretch. Other options for patching are detailed in the thread: https://github.com/apache/logging-log4j2/pull/608#issuecomme... mentions that just removing the class providing the vulnerable behavior works well, and https://github.com/Glavo/log4j-patch is a JAR that you…

The 'formatMsgNoLookups' property was added in version 2.10.0, per the JIRA Issue LOG4J2-2109 [1] that proposed it. Therefore the 'formatMsgNoLookups=true' mitigation strategy is available in version 2.10.0 and higher, but is no longer necessary with version 2.15.0, because it then becomes the default behavior [2][3]. If you are using a version older than 2.10.0 and cannot upgrade, your mitigation choices are: - Modi…

extirpate jndi.

personally, I'd extirpate Java too. but I'm curious: does anyone need and use jndi?

Re: Log4j RCE Found

#523

Post by xoxoxozero »

jamespwilliams wrote: post #211
morpheuskafka wrote: post #57

Anyone know of a quick way to test this just to see if it will hit the URL without setting up any exploit server to actually send any code? I guess you'd need something that reports when the DNS name gets hit (like how a DNS leak test works) but I can't find any services to do that.

There is also http://www.dnslog.cn/

Google.com

Re: Log4j RCE Found

#524

Post by xoxoxozero »

jamespwilliams wrote: post #211
morpheuskafka wrote: post #57

Anyone know of a quick way to test this just to see if it will hit the URL without setting up any exploit server to actually send any code? I guess you'd need something that reports when the DNS name gets hit (like how a DNS leak test works) but I can't find any services to do that.

There is also http://www.dnslog.cn/

optimizely.com

Re: Log4j RCE Found

#526

Post by kikowi »

orgesballa wrote: post #455
sathishv wrote: post #447

Earlier quoted context omitted.

can you please share code sample? and what versions you used? i am unable to replicate with log4j 1.2.12, slf4j 1.7.6, java8-151

Affected versions >= 2.0.0, So you are safe!

Do you have any reference about < 1.11.10 being affected? I though versions 1.x are not affected.

Re: Log4j RCE Found

#527

Post by jedwidz »

scottlamb wrote: post #372
niea_11 wrote: post #283

Earlier quoted context omitted.

The method responsible for variable substitution is here [1]. There are other lookup mechanisms, (didn't check them all) but they only retrieve environment/static values (this one [2] for example retrieves kubernetes attributes). I think the jndi one is the only one that load and execute code. Edit : I think my understanding of the docs is incorrect so ignore the next paragraph From the documentation [3], I have the…

> I agree that the input should be sanitized but only if the formatting behavior is a bug and was not intentional. The behavior is fundamentally wrong as explained by layer8's comment and in the blog post jcheng linked. Apparently it was intentional, and to me that's a million times worse than if it were a bug that could just be fixed. log4j is unsuitable for use in a way that many many people are suddenly discoverin…

> Apparently it was intentional, and to me that's a million times worse than if it were a bug that could just be fixed.

I've been on an 'archaeological dig' into the Log4j commit history, and sure enough, there's evidence that the formatting behavior was intentional from the outset.

My write-up is here: https://jedwidz.hashnode.dev/log4j-vulnerability-what-the-fa...

Re: Log4j RCE Found

#528

Post by abhishekjha »

Nursie wrote: post #456
abhishekjha wrote: post #440

Earlier quoted context omitted.

If I understand correctly most of the query params or POST body JSON gets mapped to a hashmap via Jackson and then POJOs gets created which can actually be an attack vector in terms of collison. [0] https://fahrplan.events.ccc.de/congress/2011/Fahrplan/attach... [1] https://openjdk.java.net/jeps/180 [2] https://stackoverflow.com/questions/8669946/application-vuln...

OH fair enough, that's not the attack vector that I was referring to, which is a more simple "deserialise me to something that I can use to compromise you" message, but it's another interesting vector! Security really is hard to get right.

>"deserialise me to something that I can use to compromise you"

Any paper/presentation that I can read? I seem to be having a hard time findin it.

Re: Log4j RCE Found

#529

Post by justinpombrio »

Quekid5 wrote: post #299
tmm1 wrote: post #115

Earlier quoted context omitted.

Not removed: https://github.com/apache/logging-log4j2/commit/d82b47c6fae9...

Holy moley, that's a lot of extra code... any bets on if it might contain new vulnerabilities? :)

Hahaha, giving you an upvote because new vulnerabilities have, in fact, been found. (And I think one of them relates to this new code not being sufficient? Though I'm not following much anymore.)
Post reply on HN