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

321–330 of 531 posts

Re: Log4j RCE Found

#321

Post by asddubs »

shepherdjerred wrote: post #147
asddubs wrote: post #131

Earlier quoted context omitted.

Seems like you're disagreeing on the basis of personal development rather than whether it makes sense for any given project. I think at that point it depends on whether you're primarily coding to learn or to make software

By the same token why would you roll your own instead of using a tried and true library that any experienced Java developer already knows?

put in general terms, to minimize complexity, and to a lesser extent, increase control. I'm not saying it's always worth it to do that no matter what, but for smaller things like logging, if you don't have any hugely complex needs (i.e. it won't be much effort to maintain your own solution), I would personally always prefer an in-house solution. It's all a function of effort, of course.

Re: Log4j RCE Found

#322

Post by cpu_ »

whizzter wrote: post #307
JanecekPetr wrote: post #200

Earlier quoted context omitted.

No, this is about log4j2 which is kinda new (2.0.0 was released 2014). Otherwise, yeah, this is terrible, especially since the tag doesn't even have to be in the formatting string.

Even if 2.x is the main culprit right now some one twitter started testing and it seems that 1.x might be exploitable as well.

can you share a link to the tweet/source?

Re: Log4j RCE Found

#323

Post by adamc »

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…

Just a note of appreciation for this thread. One of the things we can get out of debacles like this is a reassessment of how we should design software, and what we should look for in software designed by others. Food for thought.

Re: Log4j RCE Found

#325

Post by ec109685 »

testplzignore wrote: post #20

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 believe the idea is that it lets you augment your log line with additional information to make it easier to read versus having to do the lookup at parse time.

Re: Log4j RCE Found

#326

Post by ec109685 »

didibus wrote: post #148
Thorrez wrote: post #129

Earlier quoted context omitted.

The question isn't about the purpose of the feature. The question is why it's implemented with string parsing. In C, it's unsafe to do printf(string_variable); because variable will get parsed as a format string. The way to solve the vulnerability is printf("%s", string_variable); Is that the same in Java logging libraries? Is it well-known that the logged value will be parsed? What's the safe way to log a value in J…

The RCE isn't in the parsing. What gets parsed is a string that tells the server to make a request to another server. If you use a weird protocol for that, like jndi:ldap, you can then return a class which will be automatically loaded. So the code injection happens as the response to the remote request. The part the logger plays is that you can initiate that remote request by having the logger log some special string…

They are arguing that it’s weird that a user supplied string is ever “parsed” versus printf type behavior.

Re: Log4j RCE Found

#329

Post by scottlamb »

Spivak wrote: post #313
TheRealDunkirk wrote: post #308

176K LOC. For a logging library? Oh! It's for Java. It all makes sense now. (Yes, I've written in Java, and, of course, I used log4j in the project.) Just reminds me of this: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

Log4j has a stupid amount of features though, it's basically a full featured logging library, plus Filebeat and Logstash all in one lib.

> Log4j has a stupid amount of features though, it's basically a full featured logging library, plus Filebeat and Logstash all in one lib.

"Stupid" for once is the correct word. I don't want a feature where my log library downloads code from an LDAP server and runs it. I don't want a feature where interpolation is run not only on my hardcoded format string but also in the variables it references.

When software has many features, we often assume they're disabled unless we deliberately enable them and so they do little harm (other than increased code size). But this kind of on by default behavior is something else entirely.

Re: Log4j RCE Found

#330

Post by AtNightWeCode »

shp0ngle wrote: post #293
BinaryRage wrote: post #153

Earlier quoted context omitted.

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

A lot of libs for logging have similar convenient ways for getting usernames and so on. The error here seems to be that even though you use the lib correctly a bug was introduced that made the injected parameters a part of the layout, at least that is what people are claiming. The example from the article though is an incorrect use of the lib and one can expect the same type of issues in a lot of libs when dealing with input parameters.
Post reply on HN