Study Shows 38% of Java Apps Still Affected By Log4Shell (theregister.com) 25
An anonymous reader quotes a report from The Register: Two years after the Log4Shell vulnerability in the open source Java-based Log4j logging utility was disclosed, circa one in four applications are dependent on outdated libraries, leaving them open to exploitation. Research from security shop Veracode revealed that the vast majority of vulnerable apps may never have updated the Log4j library after it was implemented by developers as 32 percent were running pre-2015 EOL versions. Prior investigations from Veracode also showed that 79 percent of all developers never update third-party libraries after first introducing them into projects, and given that Log4j2 -- the specific version of Log4j affected by the vulnerability -- dates back to 2014, this could explain the large proportion of unpatched apps.
A far smaller minority are running versions that were vulnerable at the time of the Log4j vulnerability's disclosure in December 2021. Only 2.8 percent are still using versions 2.0-beta9 through 2.15.0 -- post-EOL versions that remain exposed to Log4Shell, the industry-coined moniker of the vulnerability's exploit. Some 3.8 percent are still running version 2.17, a post-patch version of the Java logger that's not exposed to Log4Shell attacks, but is vulnerable to a separate remote code execution (RCE) bug (CVE-2021-44832).
The researchers believe this illustrates a minority of developers that acted quickly when the vulnerability was first disclosed, as was the advice at the time, had returned to older habits of leaving libraries untouched. Altogether, just shy of 35 percent remain vulnerable to Log4Shell, and nearly 40 percent are vulnerable to RCE flaws. The EOL versions of Log4j are also vulnerable to three additional critical bugs announced by Apache, bringing the total to seven high and critical-rated issues. "At a surface level, the numbers above show that the massive effort to remediate the Log4Shell vulnerability was effective in mitigating risk of exploitation of the zero-day vulnerability. That should not be surprising," said Chris Eng, chief research officer at Veracode.
"The bigger story at the two-year anniversary, however, is that there is still room for improvement when it comes to open source software security. If Log4Shell was another example in a long series of wake-up calls to adopt more stringent open source security practices, the fact that more than one in three applications currently run vulnerable versions of Log4j shows there is more work to do.
"The major takeaway here is that organizations may not be aware of how much open source security risk they are exposed to and how to mitigate it."
A far smaller minority are running versions that were vulnerable at the time of the Log4j vulnerability's disclosure in December 2021. Only 2.8 percent are still using versions 2.0-beta9 through 2.15.0 -- post-EOL versions that remain exposed to Log4Shell, the industry-coined moniker of the vulnerability's exploit. Some 3.8 percent are still running version 2.17, a post-patch version of the Java logger that's not exposed to Log4Shell attacks, but is vulnerable to a separate remote code execution (RCE) bug (CVE-2021-44832).
The researchers believe this illustrates a minority of developers that acted quickly when the vulnerability was first disclosed, as was the advice at the time, had returned to older habits of leaving libraries untouched. Altogether, just shy of 35 percent remain vulnerable to Log4Shell, and nearly 40 percent are vulnerable to RCE flaws. The EOL versions of Log4j are also vulnerable to three additional critical bugs announced by Apache, bringing the total to seven high and critical-rated issues. "At a surface level, the numbers above show that the massive effort to remediate the Log4Shell vulnerability was effective in mitigating risk of exploitation of the zero-day vulnerability. That should not be surprising," said Chris Eng, chief research officer at Veracode.
"The bigger story at the two-year anniversary, however, is that there is still room for improvement when it comes to open source software security. If Log4Shell was another example in a long series of wake-up calls to adopt more stringent open source security practices, the fact that more than one in three applications currently run vulnerable versions of Log4j shows there is more work to do.
"The major takeaway here is that organizations may not be aware of how much open source security risk they are exposed to and how to mitigate it."
Availability (Score:4, Interesting)
Re: (Score:3)
Also, how many of them have the buggy log4j disabled? IIRC some older Ubiquiti Unifi versions used the vulnerable library, but it was possible to just delete or disable it.
Toys Left on the Front Yard (Score:2)
Re: (Score:2)
And about 1/3 is about the number of applications that run despite no support, might do something its arms-length mainliners do not understand, and operate deep infrastructure that is critical but nobody pays attention to because it's worked for the last ten years, why should we pay money to upgrade it, it ain't broke don't fix it.
...You java app of 16 years ago, that does not support TLS1.2, just isn't that special snowflake others need to tear apart and replace. If it survived PCI 2017-2018 requirments, a buffer overrun aint going to get management to fix it....
surprise (Score:2)
Re: (Score:2)
Old versions are a "feature" (Score:4, Insightful)
It seems most modern development methods push locking external dependencies to a specific version and bundling that version, never to be touched again. Of course, this starts because lots of dependent libraries/modules/etc. have no clue about backward compatibility, so it's not practical to have system-installed dependencies. Everything has to be bundled, and changing to even just a supposed bugfix-only point release runs a real risk of breaking things.
For C, shared libraries were used to reduce disk and memory (as OSes supported shared mappings) footprint; now that both are relatively plentiful, there's not much motivation for developers to try to share code.
Re:Old versions are a "feature" (Score:4, Interesting)
this starts because lots of dependent libraries/modules/etc. have no clue about backward compatibility
The problem most of the time is this. There are many projects that they gave me to maintain that I want to burn and throw away because they depend on everything and the kitchen sink (hundreds of dependencies, and the dependencies also have dependencies) and the developers of most of these dependencies don't care about backwards compatibility, so if you try to update one of these dependencies you end up with cascading failures.
What's worse, this is a recent phenomenon. My older projects you usually just need a JVM, some libs and that's it (or not even that), while my more recent projects have been made by clueless developers who copy everything that comes along without thinking about the consequences and then when the thing obviously blows up they pass it on to me to try to fix the mess.
Re: (Score:2)
There are many projects that they gave me to maintain that I want to burn and throw away because they depend on everything and the kitchen sink (hundreds of dependencies, and the dependencies also have dependencies) and the developers of most of these dependencies don't care about backwards compatibility, so if you try to update one of these dependencies you end up with cascading failures.
I don't know that I'd say they don't care, as much as backwards compatibility can be hard. In some cases, they literally don't care, but semantic versioning is supposed to help with that, meaning that you may not be able to go from 1.x to 2.x, but you should be able to go from 1.1.x to 1.2.x without breaking changes, and the 1.x branch can continue to receive updates/fixes without worrying about what 2.x does. In fact, log4j sort of worked like that: the 2.x branch broke backwards compatibility, so 1.x was
Re: (Score:3)
My problem is more with the "new generation" who really don't care about keeping things compatible. They constantly rewrite their dependencies and if you can't upgrade for whatever reason thei
Re: (Score:2)
Semantic versioning is kind of a half-ass thing though... I had to get somebody's old Node app running in a new environment recently, and found that some of the deps broke compatibility between e.g. 1.1.2 and 1.1.3. It took several hours of trial and error (and reading npm logs) to find all the broken deps and work out a functioning version for each (which of course means now this app is even more version-locked than before).
Re: (Score:2)
What's worse, this is a recent phenomenon.
Blame better tooling. It used to be a pain in the ass to pull external dependencies into a project and ensure they were properly packaged and distributed. It was worth it to just implement something yourself vs adding something from a third party.
Now we've got powerful build tools that make this trivial. Bit of an old-man trope, but many younger devs will google "how do I X" and copy+paste the first solution they find (usually including a new dependency to their build tool of choice). I've seen projects wit
Re: (Score:1)
A dumpster fire so bad and so seemingly unsolvable that the solution that has emerged is "let's package up literally every part of the OS that the application needs so we can turn "hello world" into a gigabyte download. We'll call it a container."
Baby duck syndrome (Score:2)
I call bullshit (Score:3)
Lots of security scanning tools will flag things like "you're using an old version of library X" as an issue without knowing if the application is vulnerable or not.
And that's what Veracode has done here, just a scan to see that 32 percent of the scanned projects has an old version of log4j, but that doesn't mean that 32 percent are actually vulnerable to the issue.
For example, maybe the code isn't directly logging user input, maybe user input is scrubbed, maybe they implementation uses the simple mitigation strategy of adding -Dlog4j2.formatMsgNoLookups=true to the command line to disable ldap lookups in general, etc.
The tools can't show this because they don't understand the runtime context, they just flag an issue of using an older jar.
Then again, that's not really the point in posting this kind of message, is it. It's not to raise any kind of awareness, it post is basically just a ploy to convince the c-suite that they need to run out and purchase this tool so they can scan their own applications to see if they're vulnerable...
Re: (Score:3)
Really depends on - is the app still being maintained or is it just a binary set in stone.
In the case of the former, sure it is what it is, and if the runtime never calls the vulnerable code paths in the component, I will agree the risk is essentially nothing.
If it is an app that is getting any kind of maintenance or new builds made for whatever reason, I'd say an an included component with known issues is something that needs to be fixed. Usually there is some process around adding new stuff to a project,
Re: (Score:3)
Speaking from personal experience, management don't care what the actual risk is. Red number in Nessus = bad, that's all they know. We can write a treatise on why these detections don't represent actual vulnerabilities, which management will simply not understand and disregard, or we can tell the users their old but still functional software is going away.
On the bright side, we've managed to get several departments to spend money on software maintenance so at least we can run the most recent versions of the
Log4j was packaged with a ton of stuff (Score:2)
Re: (Score:2)
Or open source apps that have been abandoned by developers and frozen in time but are still useful and downloaded. Maybe some group could dedicate themselves to going around github and updating these comatose apps.
Crappy code by crappy coders (Score:2)
What else is new?
Legacy Systems Maintenance (Score:2)
This is an old problem with a new twist. Yes, Log4J has a security hole but so do a lot of other dependencies whether FOSS or paid for. What's missing is the critical stable production support called for in SDLC practices. It never gets factored into a project but it's still a necessity. It's no different than keeping your car's tires properly inflated by checking them periodically. If a company comes in and does a vulnerability scan, management needs to own the risk if there are compromised dependencies th
Circa one in four... (Score:2)
Re: (Score:2)
You've heard of off-by-one errors, right? This is just a case of that hitting both the numerator and denominator.
Re: (Score:2)
Oh, I know very well what circa means, it's just the plural form of "circus".