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

Log4j RCE Found

lunasec.io

Post reply on HN
Print view View original

71–80 of 531 posts

Re: Log4j RCE Found

#71

Post by IncludeSecurity »

Pxtl wrote: post #53

I give up. It's got as many eyeballs in it as you could ever hope, and it's as mature as any piece of software ever could be. And its job is to write text to files. It's basically a wrapper around printf. How did this get screwed up? Security is impossible.

After having worked on software security for 20yrs+ I can tell you first hand that it is a long-term losing game. Libs, frameworks, and SDKs are written to provide functionality and interop. The more functionality/interop they have then the more popular they become and the more vulns they have.

The only winning move is not to code!

....OR learn to live in a state of constant vulns and put guardrails in place so that you can avoid shooting yourself in the foot as much as possible. In this case strict ngress/egress firewall rules in prod would prevent this from ever being exploited from what I've read on the vuln thus far.

Re: Log4j RCE Found

#72

Post by eyelidlessness »

jimrandomh wrote: post #64

I try to follow a rule with libraries: if a library causes more trouble than the implementation effort it would take to recreate its functionality from scratch (or rather, the portion of its funcitonality that is used in practice), then it's time to purge that library from projects and never use it again. The part of log4j functionality that gets used in practice, most of the time, is just a wrapper around printf whi…

I haven’t used log4j (or a JVM language) for several years but IIRC the most common usage was printf + agnostic but reliable output, commonly adapted to multiple SaaS solutions and usable in dev, and outputting formats that are searchable eg in Logstash. This is roughly the same as I’ve encountered on Node where I’ve also had to remind myself that it isn’t a simple printf -> stdout, even if it looks and feels like it is.

The complexity in logging libraries like this are much greater than they seem like they should be, specifically because they’re designed to abstract a lot of integration use cases in a way that feels like it just works. Marshaling data between even a few services introduces a lot of potential for mistakes.

Re: Log4j RCE Found

#73

Post by lvh »

dylan604 wrote: post #54
a-dub wrote: post #50

so the question is, is it safe to log unsanitized inputs? i've argued no given the complexity of today's logging pipelines and caught a lot of flak for it in the past... now i feel vindicated.

Why would you ever trust user provided input? Like seriously, ever? I don't trust my own input. I tend to copy&paste, and I've messed up from pasting something that was previously in the clipboard because I didn't actually hit the right keyboard shortcut when I was copying the data I thought I was. I wasn't even attempting to be malicious, but I accidentally tried a SQL Inject attack on myself because of it. DON'T EV…

Eh. I think it's pretty reasonable that people assume their logging library doesn't have random RCE, and I think it's pretty reasonable people aren't going to be able to filter every parameter based on Log4J having a relatively obscure bug.

Re: Log4j RCE Found

#74

Post by jcims »

Does anyone in here know what url schemes are valid for JNDI and/or this bug in particular? The example is LDAP but is that the only one JNDI supports? Would HTTPS or even data urls work?

Re: Log4j RCE Found

#76

Post by jrockway »

So a lot of people sound mad that the logging library is parsing the inputs, and maybe they should be, but the truly paranoid should also be aware that your terminal also parses every byte given to it (to find in-band signalling for colors, window titles, where the cursor should be, etc.). This means that if a malicious user can control log lines, they can also hide stuff if you're looking at the logs in a terminal. Something to be aware of!

Re: Log4j RCE Found

#77

Post by jffry »

morpheuskafka wrote: post #57

Anyone know of a quick way to test this just to see if it will hit the URL without setting up any exploit server to actually send any code? I guess you'd need something that reports when the DNS name gets hit (like how a DNS leak test works) but I can't find any services to do that.

Looks like https://requestbin.net/dns is what you want, no?

I set one up (free, no account) and then when I did an nslookup or curl I saw the DNS hits coming in

Re: Log4j RCE Found

#78

Post by skim_milk »

nijave wrote: post #28

Isn't it generally considered bad practice to log user controlled data (without some form of sanitization)? I think static analyzers tend to find these since they're a type of injection attack (an attacker could insert fake log lines or otherwise interfere with the log contents)

Anyone remember printf exploits? Feels strange to still be happening in 2021. I remember accidentally finding a printf exploit in an online Nintendo DS game when I was a kid, not that I knew what I was doing but it was fun to have my name be a bunch of constantly changing random numbers using %e in my online name. Sounds like the minecraft kids are having a bunch of fun with this one now :)

Re: Log4j RCE Found

#79

Post by dang »

freeqaz wrote: post #26

Here's a write up on the exploit and how to patch it. We just wrote this up and posted it a few minutes ago (before this was even on HN, lol). https://www.lunasec.io/docs/blog/log4j-zero-day/

Ok, I think we can change the URL to that from the submitted URL (https://github.com/apache/logging-log4j2/pull/608), which doesn't provide much (any?) context for understanding what's being fixed there.

Re: Log4j RCE Found

#80

Post by Natsu »

jimrandomh wrote: post #64

I try to follow a rule with libraries: if a library causes more trouble than the implementation effort it would take to recreate its functionality from scratch (or rather, the portion of its funcitonality that is used in practice), then it's time to purge that library from projects and never use it again. The part of log4j functionality that gets used in practice, most of the time, is just a wrapper around printf whi…

It's a bit more complicated than it seems to do logging efficiently, though. Higher levels of logging really do slow you down -

https://logging.apache.org/log4j/log4j-2.2/performance.html

Post reply on HN