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

71–80 of 289 posts

Re: Log4Shell update: second Log4j vulnerability published

#71

Post by AnotherGoodName »

technion wrote: post #47
mac-chaffee wrote: post #30

Earlier quoted context omitted.

Here's the alleged original Jira ticket: https://issues.apache.org/jira/browse/LOG4J2-313 PS: Don't post snarky comments on an 8-year old Jira ticket, please.

I have read that ticket and the JNDI documentation multiple times and I still can't picture what it would look like to choose to use this. Can anyone show me a codebase that utilises this feature so we can see why?

After reading through it's a pretty bad feature. It should have been blocked. The very nature of what it does is terrible.

Some background:

JNDI alone is fine. You want to load code remotely and run it? Fine. You can do that already in other ways. No issue with JNDI here, go ahead and use it on your server in a controlled way that doesn't involve user input.

Log4j has a 'routing appender' that can conditionally write to different logs depending on the content being logged. https://logging.apache.org/log4j/2.x/manual/appenders.html#R...

I can see a use to string match and send logs different ways.

Now unfortunately this patch flat out uses the 'routing appender' to look for incoming log statements with the pattern ${jndi:logging/context-name} and load that remote JNDI class.

This is such a terrible idea that doesn't pass the sniff test. The person who approved this should have simply read the description of what it does. After matching the pattern ${jndi:logging/context-name} it puts that match into a string 'key' and runs ctx.lookup(convertJndiName(key));

It's similar to someone submitting a patch that says "I want to run eval(user_input)". The only difference is that lookup(convertJndiName()) is a little bit obfuscated since it's not called eval(). I guess the review could be mistaken that it's harmless?. Still i think it's a bad smell. I'm worried for this project. It's probably worth going through everything that 'implements StrLookup' and seeing what they do in the 'lookup(final LogEvent event, final String key)' function. Both event and key are user generated content.

Re: Log4Shell update: second Log4j vulnerability published

#72

Post by mnd999 »

freeqaz wrote: post #2

We spent a few hours writing this today due to the sh*tstorm that's hit the internet since this 2nd CVE was posted up. It took us some time to do a security analysis of it and to publish our findings. If you've patched against Log4Shell, please read this to make sure you're not still vulnerable to this 2nd CVE. In some cases, you're still vulnerable depending on how you patched. In response to this, Apache published…

Probably best to patch it anyway, some customer with a report from a dumbass jar scanning tool will moan continuously if you don’t whether you’re vulnerable or not.

Re: Log4Shell update: second Log4j vulnerability published

#73

Post by silisili »

hvgk wrote: post #70
silisili wrote: post #63

Earlier quoted context omitted.

I'd argue it's more a symptom of the Java ecosystem than anything, and probably a lot more to come. From my brief tenure with it, it seemed to be 'add everything, deprecate nothing'. I remember when writing my first Java code from reference, it all worked, then my coworkers grilled me for using some -builtin- libraries because 'nobody uses that anymore.' That, and Java does everything their own way. From bouncycastle…

This is one reason I like Go. It’s exactly the opposite to Java in that respect.

Agreed 100%. As a person who writes Go daily, I appreciate that they conformed to well established standards. The crypto is redone in Go which is a little scary, but the author is among the best in the business so I generally trust it.

Re: Log4Shell update: second Log4j vulnerability published

#74

Post by raverbashing »

siva7 wrote: post #62
mac-chaffee wrote: post #30

Earlier quoted context omitted.

Here's the alleged original Jira ticket: https://issues.apache.org/jira/browse/LOG4J2-313 PS: Don't post snarky comments on an 8-year old Jira ticket, please.

Which bugs the question who is that guy that introduced the patch?

While I can see why this would be useful (in very strict cases), one can always wonder if there was an ulterior motive to developing this "feature"

And of course, it's one thing to parse a jdni entry in a config setting, another to parse every single log message

Re: Log4Shell update: second Log4j vulnerability published

#75

Post by omnicognate »

cube00 wrote: post #35
ReaLNero wrote: post #10

Earlier quoted context omitted.

run a Digital Ocean droplet hosting the server? It's up to you if the costs justify the benefits.

This why I've given up and just pay to host anything external to scratch my self hosting itch. If they somehow manage to get in at least they won't be roaming around inside my home network. The flood of failed auth attempts and weird looking strings being sent to my web server is never ending. It might be something worth reconsidering once the world is on IPv6 and we have proper subnetting we can use at home.

Nothing I self-host on my home network is exposed to the public internet. I use Wireguard to access the home network remotely.

Re: Log4Shell update: second Log4j vulnerability published

#76

Post by raverbashing »

cube00 wrote: post #35
ReaLNero wrote: post #10

Earlier quoted context omitted.

run a Digital Ocean droplet hosting the server? It's up to you if the costs justify the benefits.

This why I've given up and just pay to host anything external to scratch my self hosting itch. If they somehow manage to get in at least they won't be roaming around inside my home network. The flood of failed auth attempts and weird looking strings being sent to my web server is never ending. It might be something worth reconsidering once the world is on IPv6 and we have proper subnetting we can use at home.

Yes, every exposed webserver needs a heavy firewall and WAP/fail2ban/etc enabled?

Oh you tried to access wpadmin.php? IP gets banned. Too many failed ssh attempts? Banned. Tried to connect to mysql/postgresql? Not running but banned regardless.

Re: Log4Shell update: second Log4j vulnerability published

#78

Post by throwaway984393 »

It's funny that this vuln kind of already exists in other software that uses printf() allowing the user to specify the format string. (Not nearly as easy as this particular bug of course!) Maybe we'll have a mini renaissance of format string vulns now?

Re: Log4Shell update: second Log4j vulnerability published

#79

Post by indigodaddy »

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…

Interesting.. kind of like a vaccine!

Re: Log4Shell update: second Log4j vulnerability published

#80

Post by boublepop »

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 system X?

System owner: writes vendor

Vendor: No we are not vulnerable to that CVE, we are using Log4J V1

System owner: … the one that’s eol 2015, and has a bunch of other CVE’s including another RCE?

Vendor: yes

System owner:Are you going to issue an upgrade?

Vendor: No, we are not vulnerable to the latest CVE on V2 so we will not.

System vendor to central IT: They are using log4j V1, so not affected by the latest CVE, but we are vulnerable to other CVEs including RCE.

Central IT: Perfect, we’ll mark it down as no issues then, the Issue handling only covers the latest CVE.

Post reply on HN