SoylentNews is people
SoylentNews
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?
(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.
Abortion is the number one killed of children in the United States.
(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.