More Than 35,000 Java Packages Impacted by Log4j Vulnerabilities, Google Says (therecord.media) 39
Google's open-source team said they scanned Maven Central, today's largest Java package repository, and found that 35,863 Java packages use vulnerable versions of the Apache Log4j library. From a report: This includes Java packages that use Log4j versions vulnerable to the original Log4Shell exploit (CVE-2021-44228) and a second remote code execution bug discovered in the Log4Shell patch (CVE-2021-45046). James Wetter and Nicky Ringland, members of the Google Open Source Insights Team, said in a report today that typically when a major Java security flaw is found, it typically tends to affect only 2% of the Maven Central index. However, the 35,000 Java packages vulnerable to Log4Shell account to roughly 8% of the Maven Central total of ~440,000, a percentage the two described using just one word -- "enormous." But since the vulnerability was disclosed last week, Wetter and Ringland said the community has responded positively and has already fixed 4,620 of the 35,863 packages they initially found vulnerable. This number accounts to 13% of all the vulnerable packages.
How dare you mess with my "package" (Score:1)
Our IT office got several notices from vendors about components and products that need patching attention.
Re: (Score:2)
updates 25% off
Re: How dare you mess with my "package" (Score:2)
Re: (Score:2)
I still haven't found a useful explanation why this module was so widely used everywhere. It appears to be a module that only helps track changes in your environment and has absolutely no impact on the nuts and bolts of running the software it's enabled for. At this point, wouldn't it makers sense to just remove it from vulnerable software instead of patching it?
Log4J stands for "Logging for Java". Many packages use Log4J as their logging platform. Logging certainly covers a lot more than "only help track changes in your environment".
Re: (Score:2)
I have used Log4J quite a bit, but it was 1.x, so this weakness wouldn't be an issue.
But even that version was quite useful because it was easy to use and easy to define the logging format. A lot of logging will be an incredible help when things goes wrong making it possible to spot where the issue is.
The downside - a lot of log data to sift through. But that's a small price to pay.
Obligatory XKCD: (Score:5, Insightful)
Quite relevant: https://xkcd.com/2347/ [xkcd.com]
Re: Obligatory XKCD: (Score:5, Interesting)
And you don't find the xkcd diagram relevant or applicable?
Change one random developer to four, and add tens of thousands more dependent blocks above it and the diagram is almost perfect.
Re: (Score:2)
The sad part is that in reality there are also packages that have 0 maintainers and are still using a lot..
Why oh why (Score:2)
My knee-jerk reaction to this is why oh why does a logging system have to access the Internet at all? Tell me how wrong I am.
Re:Why oh why (Score:5, Insightful)
Log4j allows you to concentrate logs from any set of IP addresses, so access to the Internet as opposed to the local subnet or VLAN is a byproduct of that and lax security rules.
The exploit (very briefly) is that Log4j can be configured such that when it gets a log message with a URL in it, it attempts to enrich the log data by accessing the URL. The hacker figured out that if you injected a URL into the log with a LDAP request to a server the hacker controls, not only can you "enrich" the log data you can also give it a nice Java class (compiled) for it to execute. Which happens at the privilege level of whatever server software was using the Log4j class library. So they call the exploit Log4Shell.
The exploit would be stopped with proper firewall rules.
Re: (Score:2)
Re: (Score:2)
Note that there are a lot of other unknown vulnerabilities of the same class (reverse shell) that will also be stopped with proper firewalls. Check your firewall settings today!
Re: (Score:2)
Sounds like a really, really bad idea to provide by default. If someone really needs to log from multiple or even one IP address using URLs, then it would be better to provide an optional module that needs to be installed separately to receive the data and pass it to the logger in a different, more secure stream. This is part of the problem with providing too much in an implementation of a framework. Especially if many places don't need it. It provides more attack vectors, even if the use case doesn't use t
Re: (Score:3)
This. I can't think of any case where it is better to have it load random executable crap from a remote server rather than from a local directory with tight security restrictions.
In fact, the big fix is to turn that "feature" off.
Re: (Score:2)
Re: (Score:2)
The short answer is that you almost answered your own question: it has those features so that it can log to, for example, a database, which is configured via a named JNDI database connection.
The feature being exploited is described in detail as part of the configuration file. It describes how you can use properties from within the logging configuration. In this scenario, it makes sense: it allows you to move certain configuration (say, database passwords) out of the logging configuration and to some other c
Re: (Score:2)
Log4j allows you to concentrate logs from any set of IP addresses, so access to the Internet as opposed to the local subnet or VLAN is a byproduct of that and lax security rules.
The exploit (very briefly) is that Log4j can be configured such that when it gets a log message with a URL in it, it attempts to enrich the log data by accessing the URL.
I'm gobsmacked. It's decades since everyone realised that auto-fetching URLs is a bad idea.
Comment removed (Score:4, Insightful)
Re: Why oh why (Score:2)
All the c++ guys were told they were zealots and fired.... that is how it happened.
Re: (Score:2)
Re: (Score:2)
It would also be stopped by not doing substitutions in the log message. When send a string to a logger, I want that string to appear in the log, not some mangled version of that string. The functionality that caused this is fine in config files and even logging format strings, but not the data being logged FFS.
Re: (Score:2)
it's bad enough that if I were currently running a system using Log4j, I would consider writing my own drop-in replacement.
Follow best practices + stop logging so much!!! (Score:2)
it's bad enough that if I were currently running a system using Log4j, I would consider writing my own drop-in replacement.
Short answer: Does this impact Logback? There are alternatives to log4j
Don't log inputs from the user....done...now you're largely invulnerable. Tune your log config to not log anything else. Now you're PROBABLY invulnerable. Just be sure to patch regardless. An error message may contain user input. Truth be told, these are best practices anyway.
So Log4j fucked up bad for reasons I don't really understand why. I understand how. I don't know why....what motivated them to execute LDAP commands.
Re: (Score:2)
My knee-jerk reaction to this is why oh why does a logging system have to access the Internet at all? Tell me how wrong I am.
IMHO, it was wrong to include JNDI capabilities directly into a logging platform. Whichever software wants to log something should resolve such values directly.
Re: (Score:2)
You're absolutely right, but the feature isn't there so that I can do a JNDI lookup in my log message. It's there so the sys admin can do JNDI lookups in the config file, which makes sense: e.g. do a JNDI to find the name of a remote log server or a JDBC connection to log to.
Re: (Score:2)
It's less that, and more "positional variables". Let's say you're logging accesses to a restricted resource. You have a user ID token and you log the results of the the check. Well, to make the logs handy, you'd need to consult with the authentication server to translate that token to a name. and maybe you want to dump their permissions list in case the server is dealing with an outda
13%??? (Score:2)
After 1.5 weeks of the IT world working on this, doing all they could to patch every vulnerable server, the thought of 31,000 vulnerable open source projects which could still be hit in their most current version is depressing.
Re: About time title is right - Java issue, not Ap (Score:3)
Log4j 2 is an Apache product. So this is both a Java AND an Apache problem.
Incorrect on all accounts (Score:4, Informative)
Too many people believe this is Apache issue and not the old and tired Java problem we have been stuck with for over 10 years (if not more).
That's a pretty ignorant and uninformed statement. A programmer did something stupid in an Apache project. No language is immune from stupid programmers. Trust me, this would be worse if written in C, C++, or RUST and just as bad in Python, C#, JavaScript, or whatever language is your choice. So do you care to elaborate on your hyperbole?
...or are you one of those who failed CS 101 and think it's Java's fault? ...maybe some greybeard who had a bad experience with an Applet 15 years ago and never bothered to educate yourself to realize that there's a giant ecosystem of software successfully running on Java...much bigger than any other language at the moment? Are you jealous that your Java friends have better jobs than you? So please, enlighten us on why this is "a Java problem." I'll bet $10 you lack the knowledge nor experience to backup such a vague, bold, and ignorant statement.
Re: (Score:2)
True, but you're only arguing bad design (Score:2)
Looking at the history of JndiManager in Log4j2 ... it looks like this was designed-in to Log4j2 from the beginning. So this wasn't just one programmer making a mistake. It was a failure of imagination of the downside of this design on a larger scale than just one developer. This seems to have been considered part of a group of "architecture improvements" over original Log4j.
I haven't looked at the commit history, but from your description, it sounds like a bad design, more than a simple developer typo...so swap "programmer" for "designer" in the sentence above. However, the point remains. This bad design has nothing to do with Java or Apache. It has to do with a bad design in a commonly used module. I have no fucking clue why they chose to allow the lib to import content from remote servers, let alone actually run it. However, this is not Java's fault, which is what the c
What happened to keeping it simple? (Score:5, Insightful)
The problem here is that they kept adding features on top of features, to handle random requests and maybe even show how clever they are. That's why "Hello World" can be hundreds of megabytes if we just use a couple of frameworks.
Suppose you're using a shell script and just want the number of lines in a file, but "wc -l" accesses the Internet to check for printing the counts in Mayan numerals using the latest Unicode offerings? Would you be surprise if it broke?
The success of Unix (and Linux) has been SIMPLE and COMPOSABLE pieces. I never worry about "sort -u" trying to do something I hadn't thought of, it just works the same every time.
A.
Avoid hard dependencies. (Score:2)
However, the 35,000 Java packages vulnerable to Log4Shell account to roughly 8% of the Maven Central total of ~440,000, a percentage the two described using just one word -- "enormous."
This is why Java libraries and packages (those build with Maven at least) should minimize having 3rd-party libraries as "compile" dependencies. They should be "provided" dependencies.
It makes emergency patching a lot easier (as you just need to patch the container/provider) instead of having to scan and patch every single stupid jar in the dependency tree.
Honestly, unless a library is done some sort of low-level, tight integration with Log4J, there's no need to have a hard, embeddable dependency agains
overblown... (Score:1)
tinylog2 (Score:2)
Time to switch to tinylog2 or something similar and away from this bloated apache mess.
Some of their libs seem to be developed in an ivory tower of holier than thou and we know betterâ¦