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

51–60 of 289 posts

Re: Log4Shell update: second Log4j vulnerability published

#51

Post by gonzo41 »

mac-chaffee wrote: post #30
jancsika wrote: post #22

Who was the customer or class of customer that uses this string interpolation business? Edit: also, why was this feature requested in the first place?

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.

What an amazing thing to see, from birth to fiery explosion and then death. That feature may just be the most impactful thing that programmer did ever. And I'm not trying to be snarky, bugs happen, and so do bad features. It's just amazing the blast radius of this thing.

Re: Log4Shell update: second Log4j vulnerability published

#52

Post by jrockway »

markmark wrote: post #27
Pxtl wrote: post #8

Write simple software. The fact that log.Debug(someString) means someString is actually a format string in an elaborate domain-specific language instead of simple goddamned text is emblematic of the crisis the industry is in.

I don't use java and have never touched log4j, but structured logs are utterly fantastic and combined with an appropriate log server are far more useful than plain text.

I like structured logging but structured logging takes you away from a domain-specific language. Instead of log.Infof("fooed the bar: %v, baz=%v", msg, baz), you'd be writing log.Info("fooed the bar", zap.String("msg", msg), zap.Int("baz", baz)).

The attack surface is pretty low here, even though you're doing more than just printing to a file. There is no code injection because there is no programming language going on behind the scenes. (Of course, nothing is preventing you from writing a formatting function that compiles and runs a binary built from the log message. So you aren't intrinsically safe from stupid stuff.)

Re: Log4Shell update: second Log4j vulnerability published

#53

Post by lmm »

Hamuko wrote: post #48
lmm wrote: post #36

Earlier quoted context omitted.

log4j 2 isn't in so many things AFAIK? log4j 1.x is in everything, but that's not vulnerable.

I wouldn't be surprised if log4j 1.x is also vulnerable in many fun ways and that bad actors would be more willing to poke around log4j 1.x now in order to figure out new vulnerabilities to exploit.

My general impression for years has been that log4j2 and slf4j/logback are overengineered feature-fests whereas log4j 1.x is sane and simple.

Re: Log4Shell update: second Log4j vulnerability published

#54

Post by [deleted] »

dylan604 wrote: post #28
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 has it's downside too. At somepoint, everyone gets tired of asking for updates and waiting. People go back to "normal", and some things remain vuln. Chicken little eventually gets ignored.

[deleted]

Re: Log4Shell update: second Log4j vulnerability published

#55

Post by NaturalPhallacy »

freeqaz wrote: post #45
tbirdny wrote: post #23

Earlier quoted context omitted.

Logout4Shell is clever but would require you know where to put the string so it gets logged by the app. So, you have to know how to exploit the app. It could be in the user-agent header, or somewhere else entirely depending on the app. And, the fix wouldn't be permanent, only until the app was restarted. And, in a load-balanced environment you would need to make sure you hit each server.

That's definitely very fair! You could throw it into the constructor of your app right after you init log4j, at least. I've been surprised (and horrified) to learn that there are companies out there that _can't reboot their servers_ because they simply don't know how to bring the app back up. For them... live patching is the only options. Blows my mind, but that's reality (apparently)!

I would run screaming from such an organization.

Re: Log4Shell update: second Log4j vulnerability published

#56

Post by eitland »

freeqaz wrote: post #13

We also wrote a Log4Shell payload that will in-memory "hot patch" your server against Log4Shell. ${jndi:ldap://hotpatch.log4shell.com:1389/a} If you paste that into a vulnerable server (or even throw it into a log statement in your `main` function), that'll patch you against this until you can manage to update properly. Source code is on GitHub here[0][1] if you want to host it yourself. (This work is based on Logout…

Heh.

I remember seeing a framework for this kind of thing, i.e. using exploits to display warnings, hotpatch or otherwise patch servers back on Hackcon #1 in February 2006 in Oslo.

I think it was HP who presented it and I also can't remember hearing about it since and I think there are good reasons for that[1].

In this case however the advantages might actually outweigh the risks as long as it is done carefully.

[1]: others mention services or servers that no one know how to restart anymore.

Re: Log4Shell update: second Log4j vulnerability published

#57

Post by albert_e »

mac-chaffee wrote: post #30
jancsika wrote: post #22

Who was the customer or class of customer that uses this string interpolation business? Edit: also, why was this feature requested in the first place?

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.

interesting that this feature request was turned around in one day!

Re: Log4Shell update: second Log4j vulnerability published

#58

Post by stickfigure »

NaturalPhallacy wrote: post #55
freeqaz wrote: post #45

Earlier quoted context omitted.

That's definitely very fair! You could throw it into the constructor of your app right after you init log4j, at least. I've been surprised (and horrified) to learn that there are companies out there that _can't reboot their servers_ because they simply don't know how to bring the app back up. For them... live patching is the only options. Blows my mind, but that's reality (apparently)!

I would run screaming from such an organization.

I run screaming towards such organizations. Higher bill rates!

Re: Log4Shell update: second Log4j vulnerability published

#59

Post by orangepurple »

charcircuit wrote: post #40
cube00 wrote: post #35

Earlier quoted context omitted.

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.

Why would IPv6 make a difference? Addresses aren't private information and they aren't given out randomly.

It's easy to traverse the entire IPv4 space by brute force. Not so with IPv6

Re: Log4Shell update: second Log4j vulnerability published

#60

Post by [deleted] »

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?

[deleted]
Post reply on HN