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

Log4Shell update: second Log4j vulnerability published

lunasec.io

Post reply on HN
Print view View original

201–210 of 289 posts

Re: Log4Shell update: second Log4j vulnerability published

#201

Post by znep »

bzzzt wrote: post #133
jfoutz wrote: post #101

Earlier quoted context omitted.

I've really enjoyed your comments on this page, your blog, and the sample code you're pointing people at. This feels so much like a 90's java/flash bug, it's kind of hilarious and awesome. I think there are 2 key things (As I understand them, and I'm just some random guy, don't trust my armchair analysis) 1. The evil ldap server does not send bytecode to execute. It sends instructions about a class to create, and how…

* That class needs to be on the server already. The problem is lots of frameworks come with some pretty vulnerable classes. There are lists of 'serialization gadgets' for some potentially exploitable things if you can trigger a JVM to deserialize untrusted input.

Exactly. eg. https://github.com/frohoff/ysoserial#usage

Note the classes aren't at fault or doing anything wrong (even though you could imagine other mitigations they could use), they are just conveniently there to use if you have a vulnerability that lets you de-serialize untrusted data.

Re: Log4Shell update: second Log4j vulnerability published

#202

Post by avodonosov »

freeqaz wrote: post #21
teruakohatu wrote: post #18

Earlier quoted context omitted.

How does the hot patch work?

It uses the Log4Shell exploit to load some Java bytecode (read through this[0] blog post for context on Log4Shell). Then, once it loads that code, it scans the memory of the system and rewrites the various log4j classes that are loaded in memory. The code for that is this[1] Java file. There is a good talk on JNDI exploits in that[0] blog post if you want more details. :) 0: https://www.lunasec.io/docs/blog/log4j-zer…

More precisely, it does not rewrite classes, but just changes log4j configuration programmatically.

Re: Log4Shell update: second Log4j vulnerability published

#203

Post by hyperpape »

eMGm4D0zgUAVXc7 wrote: post #180
qalmakka wrote: post #162

(Maybe) Unpopular opinion: this whole ordeal is also due to the JRE being a clusterfuck of legacy and poor ideas. I understand it was the 90s but allowing to download arbitrary .class files from a server is _insane_, no matter how you spin it around.

Do you want Java to do deep packet inspection on all network traffic? Because Java supports naked sockets [1], so that is what you would have to do to block the network traffic from containing .class files. (Or remove the capability of real networking. I suppose we can agree that a language which doesn't support networking is quite limited in its use nowadays?) [1] https://docs.oracle.com/en/java/javase/16/docs/api/j…

I don't have a 100% settled opinion about what the JVM design should look like, so I'm not fully aggreeing with the parent poster. However, I don't think you're being fair to the spirit of the complaint. There's a difference between two scenarios:

1. You can write a raw socket, pull a class file, put it in the right place, and load it using classloaders (assuming they don't want to abolish dynamic class-loading)

and

2. The language has a conventional way of loading arbitrary classes over the network using the standard library.

Any turing complete language can download and execute code. Even if the language doesn't support it natively, you can write an interpreter that acts on some code/bytecode. However, some languages support hot-loading code over the network in a straightforward way, while others force you to do all the work yourself (with attendant limitations). In effect, those languages require you to take the gun, check that it is loaded, and very carefully point it at your own foot.

Re: Log4Shell update: second Log4j vulnerability published

#204

Post by ptha »

GreenToad wrote: post #163
jfoutz wrote: post #101

Earlier quoted context omitted.

I've really enjoyed your comments on this page, your blog, and the sample code you're pointing people at. This feels so much like a 90's java/flash bug, it's kind of hilarious and awesome. I think there are 2 key things (As I understand them, and I'm just some random guy, don't trust my armchair analysis) 1. The evil ldap server does not send bytecode to execute. It sends instructions about a class to create, and how…

> That class needs to be on the server already If you are talking about original log4shell then no! Jndi will grab a class definition from ldap, load it and then deserialize it.

Agreed, not being snarky, but isn't that what the "R" is in the (R)emote (C)ode (E)xecution is - The ability to trigger arbitrary code execution over a network (especially via a wide-area network such as the Internet)

https://en.wikipedia.org/wiki/Arbitrary_code_execution

The attacker can inject an LDAP URL with their own malicious code into a vulnerable website, via a request, that then is logged with logj4. The logging library if vulnerable will actually download and execute this remote malicious code, just by the attacker submitting the bad input. Obviously the vulnerable website needs to be logging this request information.

Re: Log4Shell update: second Log4j vulnerability published

#205

Post by bob1029 »

I thought I was in the clear, then I remembered we have a small java binary that handles conversion of PDF to images. Turns out, Apache PdfBox depends on Log4j and can be compromised by feeding any malicious PDF into it.

How many products use PdfBox right now? This github POC link is not even an hour old...

https://github.com/eelyvy/log4jshell-pdf

Re: Log4Shell update: second Log4j vulnerability published

#206

Post by corpdronejuly »

wara23arish wrote: post #196
boublepop wrote: post #80

Earlier quoted context omitted.

It’s a process circus. Once something gets raised as a critical IT issue in a large org, it’s not enough to “just fix the problem” or state that you aren’t affected due to network security etc. You have to report about it, which means you likely need a comment from a vendor. The most humorous thing for me about this entire situation is that the way reporting is handle in many orgs is: Central IT: Are we vulnerable in…

Literally happened to me the other day. Not sure though how I can make a difference when the vendor and manager seem to be buddies and any criticism of the tool falls on death ears.

I'm fighting this battle right now.

Inches from just emailing the list of CVEs to someone way above my paygrade and letting the chips fall.

Re: Log4Shell update: second Log4j vulnerability published

#207

Post by MikeKusold »

eMGm4D0zgUAVXc7 wrote: post #186
PenguinCoder wrote: post #183

Earlier quoted context omitted.

> restart everything if they need a plugin Yes. Hopefully ensures that only people authorized to actually restart the service can add arbitrary code.

Have a look at the forced restarts of Windows due to updates having become a well-hated meme to see how lucky you'll be in explaining that to the users.

Restarting an operating system is completely different than restarting an application after you enable a plug-in.

Re: Log4Shell update: second Log4j vulnerability published

#208

Post by btbuildem »

boublepop wrote: post #80
geerlingguy wrote: post #3

This is the vulnerability that keeps on giving. The annoying thing is, since it is evolving and attacks are spreading (and it has rightly gotten the attention of nearly everyone's IT department), we're hitting a stage where almost every customer is emailing daily asking for updates on mitigations based on evolving CVE discussions. I'd rather people be over-vigilant rather than pass on it, but mitigation is taking a b…

It’s a process circus. Once something gets raised as a critical IT issue in a large org, it’s not enough to “just fix the problem” or state that you aren’t affected due to network security etc. You have to report about it, which means you likely need a comment from a vendor. The most humorous thing for me about this entire situation is that the way reporting is handle in many orgs is: Central IT: Are we vulnerable in…

Large orgs make their employees feel like they don't matter, and eventually the feeling is reciprocal. It's insane to expect anyone in a 1000+ person org to go "above and beyond" their fairly regimented and supervised responsibilities.

I'm not advocating for that attitude, it's just what I've observed.

Re: Log4Shell update: second Log4j vulnerability published

#209

Post by dboreham »

watwut wrote: post #198
sporkland wrote: post #171

Earlier quoted context omitted.

I'm seeing instances of it making the debt worse rather than better. E.g. some folks are just forcing latest log4j libs into builds even for services that don't have it or need it in central dependencies, as it's more expedient than trying to be precise and only bump where necessary. Leading to more risk over time.

You mean that they are adding log4j maven dependency where there was none?

Reminds me of the advice to use two STOP statements in a Fortran program if you run it on a Cray. It's so fast that it could blow straight through the first one.

Re: Log4Shell update: second Log4j vulnerability published

#210

Post by toyg »

dylan604 wrote: post #93
jacquesm wrote: post #83

Earlier quoted context omitted.

And google: https://www.theverge.com/2019/5/21/18634842/google-passwords...

I knew it was definitely more than once. If it gets done at places like FB & G, then you know other smaller places are doing/have done it as well. They just didn't make the news, nor know it isn't a bad thing.

I mean, what if we have to troubleshoot an issue that is due to, say, the character encoding of such password? We need to see it, right?

(yes, such an issue would likely indicate you're not handling that sort of data in the right way, but fixing that would probably take three weeks and the PM is screaming FIXITNAOO because the customer is on the phone...)

(I'm not condoning this, just saying that it can look sensible at the time)

Post reply on HN