Live data from Hacker News

Log4jmemes.com: for those of us that need a laugh

log4jmemes.com

41–50 of 115 posts

Re: Log4jmemes.com: for those of us that need a laugh

#43

Earlier quoted context omitted.

I don't have an article but here's a super quick rundown. Log4j is a very common logging framework used in java. It very often gets pulled in along with other dependencies, so it's easy to be using it without even realizing it. It has a feature that allows it to download and run code just by logging specially formatted strings. So if someone get cause your server to log these strings, it will run whatever code they w…

Okay, I know I am not a Real Programmer, but even I know that user content is to be Not Trusted. Isn't it like a Security 101 principle that user content is always potentially dangerous, and to be treated accordingly?

Not every application developer realized that writing a string to a log required trusting that string (its just a text file, what could go wrong!).

Meanwhile, library developers didn't realize app devs would be feeding untrusted strings to their library.

I guess its debatable who's more at fault. I'd argue a logging library that executes the log entries as code is a hell of a footgun.

(Not a Java dev. Maybe log4j had obvious warnings on the tin? If nothing else, there is a UX lesson here.)

Re: Log4jmemes.com: for those of us that need a laugh

#44

Earlier quoted context omitted.

I don't have an article but here's a super quick rundown. Log4j is a very common logging framework used in java. It very often gets pulled in along with other dependencies, so it's easy to be using it without even realizing it. It has a feature that allows it to download and run code just by logging specially formatted strings. So if someone get cause your server to log these strings, it will run whatever code they w…

Okay, I know I am not a Real Programmer, but even I know that user content is to be Not Trusted. Isn't it like a Security 101 principle that user content is always potentially dangerous, and to be treated accordingly?

Your instinct is right, and in hindsight that's easy to say. Practically speaking, however, "treated accordingly" generally means "do not execute this string as a command (or pass it to anything that might do so, like a SQL statement)". It was entirely reasonable (though, we have now discovered, false) to expect that a logging framework would not execute the strings that it received.

Re: Log4jmemes.com: for those of us that need a laugh

#47
I spent this weekend removing Elasticsearch usage in our project. Just earlier I saw that our API wasn't responding, and was wondering how the hell someone with log4j got to us. Turns our AWS West 2 was down.

If it weren't for the fear of DDOS attacks, I'd put every webservice in a physical server in a basement somewhere and be done with it. I've been fighting this whole year to simplify and reduce the number of dependencies we use, but it's such an exhausting battle as it goes against the grain of the industry right now, and everyone almost actively works against you: build now, someone else may pay this technical debt.

Re: Log4jmemes.com: for those of us that need a laugh

#49
post #7

The one about using print/console.log/whatever lol. I've always done this, never have I used a library for this, because: - running manually? >myapp.log 2>&1 - using systemd? use journalctl - using docker/kubernetes? capture automatically the stdout/stderr of your containers and pipe them through logstash or something Real question: why would an application need to know where its logs go? This is not in the business…

> Example: Python's default logging module.

That's actually a log4j derivative, and imho quite bad.

Post reply on HN