In Log4J WTF news today…
-
I don't think we have a thread for news that are about technology and
, so I'll start one.
Zero-day in ubiquitous Log4j tool poses a grave threat to the Internet
Minecraft is the first, but certainly not the last, app known to be affected.
-
… anybody got an idea what the hell the feature in which the hole is is about, that is why the eff does log4j query LDAP?
-
@Bulb said in In WTF news today…:
… anybody got an idea what the hell the feature in which the hole is is about, that is why the eff does log4j query LDAP?
And even more, why the fuck is it running code that is returned? This smells like an intentional back door.
-
@Bulb said in In WTF news today…:
why the eff does log4j query LDAP?
Looking up format messages via JNDI?
Why would you ever want that?! (It's also used to look up message queues to write logging messages to — those queues are published within the container via JNDI, which can use LDAP — which I guess is sensible. Except I've never really thought that JNDI was sensible in the first place.)Looks like there's a mitigation described in the article.
-
@dkf … yes, there is a mitigation described: turn off the
feature.
-
Since this seems to be the official thread now: some more details on the exploit:
-
It's horrible (there's an extra stage processing the generated message string in the
MessagePatternConverterthat runs messages through aStrSubstitutordespite that being both highly surprising and rather slow) and almost everyone will have had things in exposed mode. For example, if you were building on top of Spring Boot then you were probably exposed (as its default patterns didn't have the mitigation, at least up until a few days ago anyway).There are a few possible mitigations, such as appending
{nolookup}to%m/%msgin your patterns, and the config flag described in that article. And to upgrade the log4j version to 2.15.
-
@dkf most spring boot hackers will be using starters which uses logback out of the box. Most of them shall be safe from this but not future dependency hell.
I'm still puzzled why anyone thought this was a good idea. In a logging library of all places, this is a terrible idea. Well done.
-
This vulnerability has messed up a few people's Saturday at the company I work for...
-
@loopback0 said in In WTF news today…:
This vulnerability has messed up a few people's Saturday at the company I work for...
I notified the company I'm currently at, and the reaction was a complete lack of anything. It's a betting company, so you'd think they'd want to keep things locked down. But;
https://www.youtube.com/watch?v=6uFQMKW53I4
-
It's funny how nobody cares about security for years but when an exploit finally makes the news then suddenly it's a matter of life and death to fix it ASAP.
-
@Gąska
Well yeah, but those previous vulnerabilities only happen to other people. How were we supposed to know that all our servers could get infected by ransomware?
-
Log4J2 Vulnerability and Spring Boot
Level up your Java code and explore what Spring can do for you.
Spring Boot users are only affected by this vulnerability if they have switched the default logging system to Log4J2. The log4j-to-slf4j and log4j-api jars that we include in spring-boot-starter-logging cannot be exploited on their own.
-
@loopback0 Ouch, the grin! Also, where the $hell did onebox library pick that image—it does not appear in the article (there is no image there)?
-
@Bulb said in In WTF news today…:
Also, where the $hell did onebox library pick that image—it does not appear in the article (there is no image there)?
It's in one of the
metatags on the page, I guess that's where Iframely found it.<meta name="twitter:image:src" content="https://avatars.githubusercontent.com/u/519772?v=4?s=200">
-
@loopback0 Either way it's one of a hell of a smug grin. Like Moon on the manure.
-
@Bulb said in In WTF news today…:
Ouch, the grin!
I find there's about three different kinds of avatars on gitbub:
- a shit-eating grin
- some anime stuff or another
- the auto-generated one
-
Our codebase was ruled safe because we had nothing that modern in it.
-
@loopback0 said in In Log4J WTF news today…:
@Bulb said in In WTF news today…:
Also, where the $hell did onebox library pick that image—it does not appear in the article (there is no image there)?
It's in one of the
metatags on the page, I guess that's where Iframely found it.<meta name="twitter:image:src" content="https://avatars.githubusercontent.com/u/519772?v=4?s=200">The last time I had to deal with that shit twitter was using their own tags. Even on a minor technical level, that site is cancer. Also, Facebook caches those things which can be a bitch when you're testing them.
-
apparently we have JAVA guys but they are still using 1.2.x. ... my question if this meant we were saved by being a dinosaur was left unanswered ... will poke at that wasps nests some more tomorrow ...
-
@Luhmann said in In Log4J WTF news today…:
apparently we have JAVA guys but they are still using 1.2.x. ... my question if this meant we were saved by being a dinosaur was left unanswered ... will poke at that wasps nests some more tomorrow ...
This is Java, not JavaScript. Using 10+ years old library is perfectly fine, as long as it does what it's supposed to do. Which is the case of log4j (1.2.x) - it can log your messages to file or send them over network somewhere. What more would you want? Dynamic expression resolver?
-
@Kamil-Podlesak said in In Log4J WTF news today…:
it can log your messages to file or send them over network somewhere.
What more would you want?
somebody thought it needed enough change to make a version 2 and a security hole out of it
-
@Kamil-Podlesak said in In Log4J WTF news today…:
@Luhmann said in In Log4J WTF news today…:
apparently we have JAVA guys but they are still using 1.2.x. ... my question if this meant we were saved by being a dinosaur was left unanswered ... will poke at that wasps nests some more tomorrow ...
This is Java, not JavaScript. Using 10+ years old library is perfectly find, as long as it does what it's supposed to do. Which is the case of log4j (1.2.x)
Wait, was that log4j 1.2.x or Java 1.2.x?
-
@Luhmann said in In Log4J WTF news today…:
apparently we have JAVA guys but they are still using 1.2.x. ... my question if this meant we were saved by being a dinosaur was left unanswered ... will poke at that wasps nests some more tomorrow ...
#MeToo
-
@Kamil-Podlesak said in In Log4J WTF news today…:
@Luhmann said in In Log4J WTF news today…:
apparently we have JAVA guys but they are still using 1.2.x. ... my question if this meant we were saved by being a dinosaur was left unanswered ... will poke at that wasps nests some more tomorrow ...
This is Java, not JavaScript. Using 10+ years old library is perfectly find, as long as it does what it's supposed to do. Which is the case of log4j (1.2.x) - it can log your messages to file or send them over network somewhere. What more would you want?
How about a Socketserver that deserialises untrusted data?
-
@boomzilla said in In Log4J WTF news today…:
@Luhmann said in In Log4J WTF news today…:
apparently we have JAVA guys but they are still using 1.2.x. ... my question if this meant we were saved by being a dinosaur was left unanswered ... will poke at that wasps nests some more tomorrow ...
#MeToo
#MeToo for the one impacted app that sites in my team. Seems from conversations there's a few we have in the wider company with 1.2.x.
We've had the debate over whether we should be upgrading 1.2.x even though it's unaffected by this issue. Fortunately that idea's gone away.
-
-
@Luhmann said in In Log4J WTF news today…:
@loopback0 said in In Log4J WTF news today…:
Fortunately that idea's gone away.
three cheers for
-
@Carnage said in In Log4J WTF news today…:
And even more, why the fuck is it running code that is returned?
Here is the exact why... https://issues.apache.org/jira/browse/LOG4J2-313
These things are always cases of components using other components and then those other component gets new functionality that has unintended consequences.
This is the opposite of "secure by design".
-
-
@Kamil-Podlesak said in In Log4J WTF news today…:
This is Java, not JavaScript. Using 10+ years old library is perfectly find, as long as it does what it's supposed to do. Which is the case of log4j (1.2.x) - it can log your messages to file or send them over network somewhere. What more would you want? Dynamic expression resolver?
In fact I want even less: just set the verbosity and spit the logs to standard error, and perhaps provide a bit of convenience formatting. With the spread of systemd and containers routing the messages is shuffled out of the application to separate components where it belongs. Only setting the verbosity makes some sense in the application, because generating messages just to discard them slows things down. Even setting verbosity per component ends up not being used in practice, because when debugging, one rarely knows for sure which components they need anyway.
-
@Bulb said in In Log4J WTF news today…:
Even setting verbosity per component ends up not being used in practice, because when debugging, one rarely knows for sure which components they need anyway.
It's nifty though if you have some middleware which can generate DEBUG messages but you want to keep the rest of the application generating just INFO messages.
I also frequently have 1 component which retrieves the application version and logs it on boot, and since that logs at INFO level it is nice to configure that independently from the level the rest of the application runs at.
-
@Bulb said in In Log4J WTF news today…:
@Kamil-Podlesak said in In Log4J WTF news today…:
This is Java, not JavaScript. Using 10+ years old library is perfectly find, as long as it does what it's supposed to do. Which is the case of log4j (1.2.x) - it can log your messages to file or send them over network somewhere. What more would you want? Dynamic expression resolver?
In fact I want even less: just set the verbosity and spit the logs to standard error, and perhaps provide a bit of convenience formatting. With the spread of systemd and containers routing the messages is shuffled out of the application to separate components where it belongs.
Well, you still technically need to format the message to the proper format used by the consumer. Something like GELF (but it's not the only one).
Even setting verbosity per component ends up not being used in practice, because when debugging, one rarely knows for sure which components they need anyway.
I strongly disagree here. This is something I need all the time - both in the development environment, and in production (it's invaluable for diagnosis).
-
@Luhmann said in In Log4J WTF news today…:
@Kamil-Podlesak said in In Log4J WTF news today…:
it can log your messages to file or send them over network somewhere.
What more would you want?
somebody thought it needed enough change to make a version 2 and a security hole out of it
Yeah, and I've never ever considered even using it. It looked like stupid idea from the very beginning. For me, the most surprising thing about this affair is that log4j2 is actually used quite a lot.
I wonder how much of that usage is caused by chumps just doing upgrade ("it's the same, just higher version, right?" - which is not true at all) and how many developers actually wanted log4j2.
I cannot stress that strong enough: log4j2 is not a new version of log4j; it's a completely new project that just parasites of the established name.
@loopback0 said in In Log4J WTF news today…:
How about a Socketserver that deserialises untrusted data?
You need to explicitly go and run it (it's basically standalone application). Nothing you can do by accident. And anyone with even basic knowledge of Java library knows how bad idea this is.
But yes, I personally think that this stuff should have been removed long, long time ago. Even before advent of GELF, the clearly better option was to use syslog.
-
@JBert said in In Log4J WTF news today…:
I also frequently have 1 component which retrieves the application version and logs it on boot, and since that logs at INFO level it is nice to configure that independently from the level the rest of the application runs at.
This sounds like a perfect use case for the VIP level that some logging libraries have that I always wondered when would I ever want it.
-
@Kamil-Podlesak said in In Log4J WTF news today…:
For me, the most surprising thing about this affair is that log4j2 is actually used quite a lot.
Probably because
End of Life
On August 5, 2015 the Logging Services Project Management Committee announced that Log4j 1.x had reached end of life. For complete text of the announcement please see the Apache Blog. Users of Log4j 1 are recommended to upgrade to Apache Log4j 2.
Security Vulnerabilities
A security vulnerability, CVE-2019-17571 has been identified against Log4j 1. Log4j includes a SocketServer that accepts serialized log events and deserializes them without verifying whether the objects are allowed or not. This can provide an attack vector that can be expoited. Since Log4j 1 is no longer maintained this issue will not be fixed. Users are urged to upgrade to Log4j 2.
-
@Bulb said in In Log4J WTF news today…:
@Kamil-Podlesak said in In Log4J WTF news today…:
This is Java, not JavaScript. Using 10+ years old library is perfectly find, as long as it does what it's supposed to do. Which is the case of log4j (1.2.x) - it can log your messages to file or send them over network somewhere. What more would you want? Dynamic expression resolver?
In fact I want even less: just set the verbosity and spit the logs to standard error, and perhaps provide a bit of convenience formatting. With the spread of systemd and containers routing the messages is shuffled out of the application to separate components where it belongs. Only setting the verbosity makes some sense in the application, because generating messages just to discard them slows things down. Even setting verbosity per component ends up not being used in practice, because when debugging, one rarely knows for sure which components they need anyway.
A-forking-men. Have the option to send shit to a file or to a socket, or to a UDP receiver if absolutely necessary, although with the usual Java error messages it's probably of little use. Everything else can be handled by a logshipper. This gratutious complexity is evil.
-
Y'all remember that thing I said about web UI shit?
@Steve_The_Cynic said in Do not upgrade:
The more I read about this web UI shit, the more I'm glad I don't have to do anything with it. Working half the time inside the FreeBSD kernel, half the time in userland but in close symbiosys with the kernel part of our code, I can sit back and read about e.g. leftpad and just laugh at y'all.
Enjoy.
I'm gonna say the same thing about Java, in spades.
-
@Steve_The_Cynic said in In Log4J WTF news today…:
Y'all remember that thing I said about web UI shit?
@Steve_The_Cynic said in Do not upgrade:
The more I read about this web UI shit, the more I'm glad I don't have to do anything with it. Working half the time inside the FreeBSD kernel, half the time in userland but in close symbiosys with the kernel part of our code, I can sit back and read about e.g. leftpad and just laugh at y'all.
Enjoy.
I'm gonna say the same thing about Java, in spades.
Logging in Java is one of it's most stupid parts as well. Want to speed your server up by a significant number? Remove the logging.
Or the fact that the standard logging parts are so bad that there are multiple large logging projects.
Or shit like this CVE.
-
As someone who doesn't deal with such enterprise-y Java things, all of this is way over my head.
For me, logging basically means
std::cout, or maybespdlog::infoif you want to get fancy. I get that this is just my simple view and there's requirements for more complex solutions, but why the hell logging would do name lookups, connect to servers, and execute code you send it...
-
@topspin said in In Log4J WTF news today…:
As someone who doesn't deal with such enterprise-y Java things, all of this is way over my head.
For me, logging basically means
std::cout, or maybespdlog::infoif you want to get fancy. I get that this is just my simple view and there's requirements for more complex solutions, but why the hell logging would do name lookups, connect to servers, and execute code you send it...In Java, you don't want to use system.out.print for logging in servers, since performance is horrible, and you can't separate logging to different files for different things.
If performance isn't interesting, and it doesn't matter if the framework or platform dumps all its stuff in the same place, it's perfectly fine.
-
@topspin said in In Log4J WTF news today…:
As someone who doesn't deal with such enterprise-y Java things, all of this is way over my head.
For me, logging basically means
std::cout, or maybespdlog::infoif you want to get fancy. I get that this is just my simple view and there's requirements for more complex solutions,syslog/syslogd was already a wide accepted standard in early 1990s. I don't know if it counts as "fancy" and "enterprise-y", but definitely has pretty much all features required from loggers today (level+facility, different log files, network protocol). Of course, in barebone form (the facilities, in particular, are quite limited).
but why the hell logging would do name lookups, connect to servers, and execute code you send it...
Yes,
indeed. The fact that there are at least 3-4 other libraries to use might be a , but AFAIK none of them do any of this.
-
@Kamil-Podlesak said in In Log4J WTF news today…:
@topspin said in In Log4J WTF news today…:
As someone who doesn't deal with such enterprise-y Java things, all of this is way over my head.
For me, logging basically means
std::cout, or maybespdlog::infoif you want to get fancy. I get that this is just my simple view and there's requirements for more complex solutions,syslog/syslogd was already a wide accepted standard in early 1990s. I don't know if it counts as "fancy" and "enterprise-y", but definitely has pretty much all features required from loggers today (level+facility, different log files, network protocol). Of course, in barebone form (the facilities, in particular, are quite limited).
More importantly, it does those things outside the application. In the application you just call
openlogto tell it which facility you are and then throw the logs over the wall with a simplesyslogfunction and the rest is none of the application's business.But no, everybody has to embed a logging library that does all those damn things itself. Especially java where the community suffered NIIJ syndrome.
-
@Bulb Depending on what you're doing, I don't think syslog is appropriate for arbitrary applications. Moreover, it's output is generally not accessible to normal users.
-
@PleegWat said in In Log4J WTF news today…:
normal users
Like Bob the accountant on the 4th floor who is probably using a Windows application to do his work? I find it particularly funny how *nix land thinks it has "normal" users.
-
@CodeJunkie I'm in commercial product land. Our product does everthing under an unprivileged daemon user and does not normally have access to root-level functionality.
One of the functions in our web interface allows downloading a diagnostics bundle so development can troubleshoot any issues. This diagnostics bundle is created by the daemon user, so anything that user cannot access cannot be in the bundle.
-
@PleegWat said in In Log4J WTF news today…:
@CodeJunkie I'm in commercial product land. Our product does everthing under an unprivileged daemon user and does not normally have access to root-level functionality.
One of the functions in our web interface allows downloading a diagnostics bundle so development can troubleshoot any issues. This diagnostics bundle is created by the daemon user, so anything that user cannot access cannot be in the bundle.
We have a bunch of legacy machines where developers have read-only access to logs, not a big deal and way more practical than having the webserver bundle up potentially hundreds of MB. Everything new is containerized and needs to ship the logs to Elasticsearch.
-
@loopback0 quoted in In Log4J WTF news today…:
Spring Boot users are only affected by this vulnerability if they have switched the default logging system to Log4J2. The log4j-to-slf4j and log4j-api jars that we include in spring-boot-starter-logging cannot be exploited on their own.
He's right and wrong at the same time. Spring Boot doesn't log with log4j by default, yes, but (unless they've released an update in the past 24 hours) they do profile
log4j-coreto be a buggy version if you use it. Which is “fun”. You can override that, but you need to pay attention to what version is actually used in your build. (Fortunately, if you're using Spring Boot, you're probably using a build system where sorting this out isn't difficult.)
-
@dkf said in In Log4J WTF news today…:
He's right and wrong at the same time. Spring Boot doesn't log with log4j by default, yes, but (unless they've released an update in the past 24 hours) they do profile log4j-core to be a buggy version if you use it. Which is “fun”.
The only version of Spring we have in use in my team hadn't even shipped withlog4j-core, just the other two.
-
@loopback0 said in In Log4J WTF news today…:
The only version of Spring we have in use in my team hadn't even shipped with
log4j-core, just the other two.It doesn't ship with it. It ships with a version constraint on it in its metadata.
NVD - CVE-2019-17571
