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

391–400 of 531 posts

Re: Log4j RCE Found

#391

Post by keyle »

robertelder wrote: post #382

I've been thinking about this since I saw it here on HN yesterday, and I can't help but entertain the idea that this might end up being 'the worst software security flaw ever'.

We need proactive logging to see when something dodgy is going on!

    *boned by proactive logging*

Re: Log4j RCE Found

#392

Post by [deleted] »

robertelder wrote: post #382

I've been thinking about this since I saw it here on HN yesterday, and I can't help but entertain the idea that this might end up being 'the worst software security flaw ever'.

[deleted]

Re: Log4j RCE Found

#394

Post by blibble »

robertelder wrote: post #382

I've been thinking about this since I saw it here on HN yesterday, and I can't help but entertain the idea that this might end up being 'the worst software security flaw ever'.

absolutely, most vulnerabilities are stopped by the frontend

this one gets all the way through and hits the backend

better hope your backend is on a separate LAN with no internet access..!

Re: Log4j RCE Found

#395

Post by the8472 »

dokem wrote: post #388

I haven't read into the specifics of this issue but doesn't a RCE vulnerability in a Java library really rest on a RCE vulnerability in Java/JRE itself?

Not necessarily, java has explicit mechanisms for dynamic code loading (classloaders) and if those are reachable from unsanitized user input then you have what amounts to a very indirect and enterprise-grade eval().

Re: Log4j RCE Found

#396

Post by brabel »

robertelder wrote: post #382

I've been thinking about this since I saw it here on HN yesterday, and I can't help but entertain the idea that this might end up being 'the worst software security flaw ever'.

We tested this on several JVM versions and found you needed to go really far back, to around Java 8u121 I think, to see the specific exploit using LDAP+HTTP class loading work because they changed the value of the JVM property that allows loading a class file from a remote codebase... however, as this article points out, quite mind blowingly, early JDK11 releases also seem to have been vulnerable (I believe at least JDK 11.0.2 is not vulnerable anymore, but can't confirm right now).

We also found that other similar exploits based on JNDI can work even if the one based on LDAP redirecting class loading to a malicious HTTP server doesn't (I won't mention it here because it makes it much easier to exploit, so disabling log4j's evaluation of jndi patterns or migrating to the patched version is absolutely necessary, still).

Re: Log4j RCE Found

#398

Post by dbt00 »

jimbob45 wrote: post #397

Is there any reason to believe this wouldn't affect log4net in the same way?

No reason to think that it is -- it's related to a specific implementation of a java technology, it would require completely a completely hypothetical parallel track.

Re: Log4j RCE Found

#399

Post by anyfoo »

dylan604 wrote: post #389
robertelder wrote: post #382

I've been thinking about this since I saw it here on HN yesterday, and I can't help but entertain the idea that this might end up being 'the worst software security flaw ever'.

nah, it's just a logging package that not everyone uses. it would be much worse if it was in an OS of some sort.

Would it? It's a very common logging package, and Java is cross-platform. I also think OSes tend to be updated more often than JDKs (but I'm not sure).
Post reply on HN