Java Code Repository Riddled with Hidden Log4j Bugs; Here's Where to Look:
About 17,000 Java packages in the Maven Central repository, the most significant collection of Java packages available to developers, are vulnerable to Log4j — and it will likely take "years" for it to be fixed across the ecosystem, according to Google security.
Following the CVE update that just Log4j-core was affected, eliminating vulnerable instances of the Log4j-api, Google Security determined that as of Dec. 19, more than 17,000 packages in Maven Central were vulnerable, about 4 percent of the entire repository. Of those, just 25 percent of the packages had updated versions available, Google added.
For comparison, the Google researchers explained in a Tuesday blog post that the average bug affects between 2 percent and less than .01 percent of such packages.
Sonatype, the organization which maintains Maven Central, has a dashboard that's updated several times a day with the latest on Log4j and reported that since Dec. 10, more than 40 percent of the packages being downloaded were still vulnerable, totaling nearly 5 million downloads.
[...] "The majority of affected artifacts come from indirect dependencies (that is, the dependencies of one's own dependencies), meaning Log4j is not explicitly defined as a dependency of the artifact, but gets pulled in as a transitive dependency," the Google team said.
Making these unpatched Log4j versions even sneakier to track down is "how far down the software supply chain it's typically deployed," the analysts added.
"For greater than 80 percent of the packages, the vulnerability is more than one level deep, with a majority affected five levels down (and some as many as nine levels down)," the report warned. "These packages will require fixes throughout all parts of the tree, starting from the deepest dependencies first."
[...] "Propagating a fix often requires explicit action by the maintainers to update the dependency requirements to a patched version," the Google researchers said. "This practice is in contrast to other ecosystems, such as npm, where it's common for developers to specify open ranges for dependency requirements."
[...] To help out, Google has pulled together a list of the 500 most-used and impacted Java code packages.
"We looked at all publicly disclosed critical advisories affecting Maven packages to get a sense of how quickly other vulnerabilities have been fully addressed," the team said. "Less than half (48 percent) of the artifacts affected by a vulnerability have been fixed, so we might be in for a long wait, likely years."
See Also:
Third Log4J Bug Can Trigger DoS; Apache Issues Patch
Log4j vulnerability now used to install Dridex banking malware
The 'most serious' security breach ever is unfolding right now. Here's what you need to know.
What's all the fuss with Log4j2?
Google Finds 35,863 Java Packages Using Defective Log4j
Log4j software bug: What you need to know
Previously:
Log4j Security Flaw Could Impact the Entire Internet; Attackers Switch to Injecting Monero Miners
'The Internet's on Fire': Techs Race to Fix Major Cybersecurity Software Flaw
Related Stories
'The Internet is on Fire'
The problem lies in Log4j, a ubiquitous, open source Apache logging framework that developers use to keep a record of activity within an application. Security responders are scrambling to patch the bug, which can be easily exploited to take control of vulnerable systems remotely. At the same time, hackers are actively scanning the internet for affected systems. Some have already developed tools that automatically attempt to exploit the bug, as well as worms that can spread independently from one vulnerable system to another under the right conditions.
Log4j is a Java library, and while the programming language is less popular with consumers these days, it's still in very broad use in enterprise systems and web apps. Researchers told WIRED on Friday that they expect many mainstream services will be affected.
For example, Microsoft-owned Minecraft on Friday posted detailed instructions for how players of the game's Java version should patch their systems. "This exploit affects many services—including Minecraft Java Edition," the post reads. "This vulnerability poses a potential risk of your computer being compromised." Cloudflare CEO Matthew Prince tweeted Friday that the issue was "so bad" that the internet infrastructure company would try to roll out a least some protection even for customers on its free tier of service.
All an attacker has to do to exploit the flaw is strategically send a malicious code string that eventually gets logged by Log4j version 2.0 or higher. The exploit lets an attacker load arbitrary Java code on a server, allowing them to take control.
"It's a design failure of catastrophic proportions," says Free Wortley, CEO of the open source data security platform LunaSec. Researchers at the company published a warning and initial assessment of the Log4j vulnerability on Thursday.
The Log4j security flaw could impact the entire internet. Here's what you should know:
A critical flaw in widely used software has cybersecurity experts raising alarms and big companies racing to fix the issue.
[...] Jen Easterly, head of the Department of Homeland Security's Cybersecurity and Infrastructure Security Agency (CISA), called it "one of the most serious flaws" seen in her career. In a statement on Saturday, Easterly said "a growing set" of hackers are activelyattempting to exploit the vulnerability.
[...] "It will take years to address this while attackers will be looking... on a daily basis [to exploit it]," said David Kennedy, CEO of cybersecurity firm TrustedSec. "This is a ticking time bomb for companies."
[...] "It's ubiquitous. Even if you're a developer who doesn't use Log4j directly, you might still be running the vulnerable code because one of the open source libraries you use depends on Log4j," Chris Eng, chief research officer at cybersecurity firm Veracode, told CNN Business. "This is the nature of software: It's turtles all the way down."
[...] It could [be] present in popular apps and websites, and hundreds of millions of devices around the world that access these services could be exposed to the vulnerability.
(Score: 3, Funny) by DrkShadow on Wednesday December 22 2021, @01:56AM (12 children)
Java Code Repository Riddled with Hidden Log4j Bugs; Here's Where to Look
*scrolls on in disinterest*
(Score: 0) by Anonymous Coward on Wednesday December 22 2021, @02:17AM
What's the Flemish for pwned? [theregister.com]
(Score: 0) by Anonymous Coward on Wednesday December 22 2021, @02:24AM
Right now I so wish that I could sit across the desk of my manager from 18 years ago. "I should learn Java, you say?" Same manager who asked me to write "my magic" (Perl to quote: "verify the Java data structures we are producing..." I'm having a genuine BOFH moment right now. But that manager is long retired by now and the company swallowed by a bigger fish.
(Score: 2, Interesting) by Anonymous Coward on Wednesday December 22 2021, @03:24AM (9 children)
He's the guy who said "the network is the computer." Remember back to his vision of diskless workstations that would oull code from all over the internet to be assembled on the fly into applications? A very naive idea, but it means Java was always broken by design.
In other words, "WORKS_AS_DESIGNED." So it's a feature , not a bug. And people wonder why real programmers laugh at slow, stupid, over-designed Java weenies a quarter century later … because we were right all along - it was shitty from the get-go.
(Score: 2) by HiThere on Wednesday December 22 2021, @04:11AM (5 children)
FWIW, it's probably possible to write safe code in Java, and Java is far from the only language that depends on downloading libraries from the net. It's not even the only one to do it dynamically, which is a clear danger unless you have each item signed & know the proper signature.
There's often a choice between convenient and safe, or between fast development and safe development. How you should optimize isn't always clear.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 2, Funny) by Anonymous Coward on Wednesday December 22 2021, @11:27AM (1 child)
>> FWIW, it's probably possible to write safe code in Java,
Yes, as long as the first line is /* and the last line is */
(Score: 2) by hendrikboom on Thursday December 23 2021, @04:29AM
/*
*/
horrible code
/*
*/
(Score: 2) by choose another one on Wednesday December 22 2021, @01:19PM (2 children)
So, to paraphrase: Running code from anywhere is a clear danger unless it is properly signed.
That's right folks, it doesn't matter if the code was specified in the book of the damned, crafted in the fires of hell, and packaged in the colon of Beelzebub himself, as long as he properly signed it when he shat it out it's good to run.
You know, I was looking at the history of this vulnerability and how it arose and was reckoning there was an entire dissertation in it without straying from the things that were grossly incompetent, should have been seen to be without hindsight, and therefore may cross the line into professional negligence - in other fields... If you widened the view to cover the state of the industry and development in general I think there'd be a thesis (or several) in it. But no, you just had to summarise it in one damned line (albeit a longish one).
(Score: 3, Touché) by HiThere on Wednesday December 22 2021, @02:33PM (1 child)
If it's properly signed, you can choose whether you trust the author. Otherwise...
It's a good point that signing isn't in-and-of-itself sufficient. But without signing you're operating blindly unless you personally examine every line of code and even then you'ld better not miss anyting.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: -1, Offtopic) by Anonymous Coward on Wednesday December 22 2021, @03:54PM
(Score: 0) by Anonymous Coward on Wednesday December 22 2021, @08:20AM
(Score: 3, Interesting) by choose another one on Wednesday December 22 2021, @01:33PM (1 child)
Actually, although I hate to differ on this, Java wasn't (so) broken from the start.
If you look at the history of the security model ( https://docs.oracle.com/javase/7/docs/technotes/guides/security/spec/security-spec.doc1.html [oracle.com] ), version 1.0 is
(a) simple
(b) clear and easy to understand
(c) safe from RCE modulo sandbox failures/escapes
(ie. design was safe, implementation might not have been watertight, somewhat like a lot of my DIY).
It's been ****ed up since, if you read down (note, you're only going as far as v1.2, or end of last century) it rapidly becomes TL;DR; and:
(a) complex
(b) possibly beyond what the dev can understand and definitely beyond what the dev is paid to understand and
(c) unsafe, or at least easy to make unsafe if you don't understand it, see (b)
But here's the thing: all the advertising, all the marketing, all the pitch that got people into the language was based on 1.0 - ie. "Java is safe".
It isn't, now, but it was at least designed to be in the beginning, and marketed based on that design.
(Score: 2) by HiThere on Wednesday December 22 2021, @02:36PM
It still wouldn't have been safe to use Java, even 1.0, in the way they advertised. (Well, some of the ways would have been ok, but not to use in the way JavaScript is currently used...which JavaScript isn't that safe for either.)
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 3, Insightful) by Anonymous Coward on Wednesday December 22 2021, @02:28AM (6 children)
If you don't know what you're building maybe you should. On the other hand, the build system should make it *very* clear what exactly gets added to the build.
(Score: 2) by mth on Wednesday December 22 2021, @04:56AM (5 children)
The problem seems to be that with Maven the versions of transitive dependencies are being locked instead of pulling in the latest release of the same major version. As the article notes:
So even if you are keeping an eye on transitive dependencies that are pulled into your build, you'd have to wait for all library maintainers to update their packages before you get the fixed version of log4j2 installed.
(Score: 2) by PiMuNu on Wednesday December 22 2021, @09:20AM (3 children)
...which makes sense because a change in a dependency can break your code. Hence "dependency".
(Score: 2) by mth on Wednesday December 22 2021, @10:16AM (2 children)
Indeed sometimes changes, even if they were intended to be compatible, can break things. However, when it comes to security, things are broken when you don't update. Overall I prefer to let the application developer rather than the individual package maintainers lock the exact versions.
(Score: 3, Interesting) by bradley13 on Wednesday December 22 2021, @12:28PM (1 child)
This is the problem. Look at the libraries: each one brings in half-a-dozen others. Transitively.
I used to have a really simple demo-project that used a single library. Came the day, someone modified something and decided they wanted to use some function from another library. I followed the transitivity three layers down, in a kind of blind daze: in the end, there were something like 20 libraries, most of which I had never heard of.
How are you supposed to know which ones need security updates? What's might break when you install an update to one of the libraries in the chain? It is literally not possible. This is yet another verison of "DLL hell".
Everyone is somebody else's weirdo.
(Score: 2) by PiMuNu on Wednesday December 22 2021, @03:17PM
I guess it forces the good practice of insisting to unit test all of your stuff to death. Wrap third party libraries and test to death. Use reproducible tests (i.e. test scripts).
Of course, we all do this anyway.
(Score: 0) by Anonymous Coward on Wednesday December 22 2021, @02:06PM
The idea that you can build applications dynamically from classes downloaded from servers you don't control and just run them is incredibly stupid. Because it's insecure by design. Same crap as javascipt.
And just because there are also other languages that do this doesn't make it any smarter.
"Oh but it's open source. Many eyes make all bugs shallow." Obviously a lie that nees to die. And you can be sure there are "many eyes" - not very friendly - looking. Not even "security by obscurity ".
Merry fucking christmas.
(Score: -1, Offtopic) by Anonymous Coward on Wednesday December 22 2021, @03:02AM (1 child)
You'll find treasures galore!
(Score: 0) by Anonymous Coward on Wednesday December 22 2021, @02:21PM
(Score: 0, Touché) by Anonymous Coward on Wednesday December 22 2021, @04:20AM (3 children)
How did anyone ever end up using this crap riddled language?
(Score: 2, Funny) by Anonymous Coward on Wednesday December 22 2021, @04:42AM (2 children)
The problem is not in the language, but in the library requirements.
(Score: 0) by Anonymous Coward on Wednesday December 22 2021, @02:15PM
Remember thatt joke about if how houses were built like software,woodpeckers would end civilization? Java is a great example of a fragile brittle software ecosystem.
(Score: 2) by Freeman on Wednesday December 22 2021, @04:11PM
The problem is not the bonfire, it's the many tiny sticks that make up that bonfire.
Joshua 1:9 "Be strong and of a good courage; be not afraid, neither be thou dismayed: for the Lord thy God is with thee"
(Score: 2) by bradley13 on Wednesday December 22 2021, @12:05PM (3 children)
Any chance that this will teach developers to randomly bolting together libraries, instead of implementing stuff themselves?
No, of course not, because the skill level of the average developer is...poor. And the average PM puts cost cutting and speed of delivery ahead of everything else. The classic PM triangle: fast, cheap, good.
Reminds me of a bit of consulting I did for a company a few years ago. They had just hired a new DB admin, and I was supposed to explain the structure of a database to get them up to speed. I spent most of the time answering questions about how to write SQL queries, what was a join, why did we have primary keys, etc... Diversity hire? Accepted a low salary? Probably both. Whatever, I eventually told the boss "look, I'm not here as an SQL tutor". And that was the *only* DB admin they had...
Everyone is somebody else's weirdo.
(Score: 2) by Freeman on Wednesday December 22 2021, @04:13PM
Reinventing the wheel, yet again, for the 2147483647th time.
Joshua 1:9 "Be strong and of a good courage; be not afraid, neither be thou dismayed: for the Lord thy God is with thee"
(Score: 0) by Anonymous Coward on Wednesday December 22 2021, @09:40PM
Diversity hires are supposed to be work to put qualified people who aren't white and Asian men into positions that were formerly only available to white and Asian men. Hiring someone under qualified is just a fuckup, period.
Yes, I've worked with black idiots, and women idiots, and black women idiots. I've also worked with white men that are idiots too. The commonality was 'idiot', and the cause was often that the company was trying to fill the position at 60% the rate of a qualified candidate. Don't blame the problem on gender or skin tone.
(Score: 0) by Anonymous Coward on Thursday December 23 2021, @10:47AM
If you want to implement everything yourself are you using your own web browser and OS to read this site?
If the average coder uses libraries that are above average then the average quality of the resulting stuff will actually go up, compared to if the average coder wrote everything.
FWIW I use my own log library because I don't need high performance, but when errors happen I want the context to be logged in detail as well. For example, normally all the debug log stuff actually goes into a ring buffer and only the NOTICE and WARNING stuff gets logged to the log files. But when there's an ERROR then the contents of the buffer are dumped into the log file as well, so the log isn't cluttered with debug level stuff unless there are errors. So far this approach works well for my use cases. I very rarely log stuff in a high performance loop anyway.
(Score: 1, Funny) by Anonymous Coward on Wednesday December 22 2021, @03:31PM (1 child)
If the dependency problem is several layers deep, wouldn't that mean that most code are using the same underlying libraries making it easier to fix?
(Score: 0) by Anonymous Coward on Wednesday December 22 2021, @04:14PM
Look at how many "developers " pull in 3 different libraries to do different things because they don't know that they could just RTFM and the functions they want are available in all 3 libraries. Just different names because people love to reinvent the wheel.
And then there's disagreement over things like rounding - does .5 round up or down. Round up odd fractions, round down even fractions (or vice versa - hint - both are wrong 50% of the time, fuck you Bill Gates for fudging it).
And using double as a type for coordinates when creating a 2-d gui? And you wonder why people don't create traditional int-based gui components with the ability to be absolutely positioned rather than the shit that leads to really crappy UIs using the native layout managers.
And the PLAFs (Pluggable Look and Feel) libraries are mostly REALLY ugly.
Maybe it's time to rip out everything after Java 1.5, dump J2Ee, and simplify whatever is left. Swing will always suck.
(Score: 0) by Anonymous Coward on Wednesday December 22 2021, @05:18PM
On the desktop Microsoft and Apple are the only significant platforms.
On mobile? Android can't run native java classes, and Apple doesn't have a jre for IOS (for both battery life and security).
So if you're going to do anything, might as well pick your platform and use a real natively compiled language. Apple or Microsoft . Because multi platform support is simply not necessary for success.