Live data from Hacker News

Log4j RCE Found

lunasec.io

291–300 of 531 posts

Re: Log4j RCE Found

#293

I don't get what the point of this feature even is. What is a legitimate reason for a logging library to make network requests based on the contents of what is being logged? And is this enabled out-of-the-box with log4j2?

log4j2 supports lookups, which allows you to add additional logging context: https://logging.apache.org/log4j/2.x/manual/lookups.html The problem here is the JNDI lookup because for historical reasons there is code in these providers which causes Java to deserialize and load bytecode if it's found in a result for a lookup against an LDAP server. That exploit was partially fixed in the JDK in 2008, then in 2018, but t…

I don’t understand these Java protocols enough to understand why was loading arbitrary bytecode from URLs even considered a feature, but I guess it was the 90s and Objects were all the rage

Re: Log4j RCE Found

#294

Earlier quoted context omitted.

I disagree strongly with this. You're better off learning the de-facto libraries of your language. Your employer, or any production application you're going to work on is probably going to use one of these libraries. I learned the most common Java libraries when writing personal projects -- Lombok, log4j, Guava, Gson, Jackson, Netty, etc. I had a significantly gentler learning curve at my first job. We used these com…

avoid google libraries like the plague, there's absolutely no need for them unless you're using protobuf. I don't understand why people are using lombok after java 16. Jackson and log4j are sort of essential, unfortunately. more libraries = more attack surface.

For an enterprise to move to Java 16, a huge amount of code needs to be reviewed and tested. It's not as simple as incrementing a number in 200 pom.xml files.

Sure records are pretty cool but Lombok does do a few other things as well.

Re: Log4j RCE Found

#295
post #24

I don't get what the point of this feature even is. What is a legitimate reason for a logging library to make network requests based on the contents of what is being logged? And is this enabled out-of-the-box with log4j2?

I'm guessing some sort of auditing or routing functionality. For instance, you have debug logs going to some development server and login events going to so audit server. I don't have experience with this feature but there's similar use cases in log shipping utilities like fluentd Edit: I read the other link and it looks like some sort of poorly designed RPC functionality or something shrug Edit 2: Reading https://do…

Reading about this got me to the words “servlet” and “BeanFactory”, which I don’t really want to uncover right now, as it might open some pandora’s box

Re: Log4j RCE Found

#296
post #215

Earlier quoted context omitted.

This is just stupid. Logging should not do any side effects except writing to the log.

I'm not defending Log4j, but this error can really happen to many logging libraries. All logging libraries contain some kind of template engine as a performance optimization, in order to avoid actually generating the output string (can be costly) if logging is disabled. And template engines have always been a major source of vulnerabilities.

There are several ways to avoid generating log strings that don't involve sketchy ad-hoc templating. Use a language with laziness, put the string generation in a lambda expression, use a language with a good compiler and don't put side effects in your log string expression, etc.

As a matter of principle, it should also clearly not be possible for a templating engine to perform any kind of side effect. That's totally crazy.

Re: Log4j RCE Found

#297
post #288
post #195

Earlier quoted context omitted.

I don't really know what's going on here, so to clarify... it gives "simple checking example" nslookup mydatahere.a54c4d391bad1b48ebc3.d.requestbin.net but when I run that in my terminal I get the response ;; Got SERVFAIL reply from 83.146.21.6, trying next server Server: 212.158.248.6 Address: 212.158.248.6#53 ** server can't find mydatahere.a54c4d391bad1b48ebc3.d.requestbin.net: SERVFAIL And nothing shows up in "re…

I'm not Requestbin's creator so I don't know. A simple nslookup or curl does work for me, with my system's DNS servers set to Cloudflare (1.1.1.1) or Google (8.8.8.8) It looks like Vodafone (I assume this is your ISP) DNS servers aren't properly resolving the name for some reason. You could try bypassing it with dig, and directly ask a different DNS server to resolve it: dig @1.1.1.1 A whatever.a54c4d391bad1b48ebc3.d…

Thanks! Yeah, `dig` with no DNS gives me a SERVFAIL but `dig @1.1.1.1` works.

My ISP isn't Vodafone directly (I take it you think that because 83.146.21.6 belongs to them?) but might be a Vodafone reseller or something.

Re: Log4j RCE Found

#298
post #191
post #110

Earlier quoted context omitted.

While that's an interesting vector for attack, is it realistically an issue? Terminals are run as root all the time. I would guess any mainstream ones are well reviewed to not have such exploits work. Are you aware of any actual attacks exploiting terminal parsing in the wild?

Classic confusion: terminals typically run as users, but the shells in them often run as root. I could imagine an attack like this: printf 'rm -rf /\n\033[%iAecho "Hello World!"\n' When executed in a terminal this looks like it generates an innocent shell script. But when piped into a file and the executed it will delete all your files.

I think you meant \r instead of \n immediately after the / ?

Re: Log4j RCE Found

#299
post #115

Earlier quoted context omitted.

Which is why they removed the functionality in the latest version (per comments below) right?

Not removed: https://github.com/apache/logging-log4j2/commit/d82b47c6fae9...

Holy moley, that's a lot of extra code... any bets on if it might contain new vulnerabilities? :)

Re: Log4j RCE Found

#300
post #110

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

While that's an interesting vector for attack, is it realistically an issue? Terminals are run as root all the time. I would guess any mainstream ones are well reviewed to not have such exploits work. Are you aware of any actual attacks exploiting terminal parsing in the wild?

>Terminals are run as root all the time. I would guess any mainstream ones are well reviewed to not have such exploits work

This is a really ridiculous assumption.

Post reply on HN