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: 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.
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.
(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.
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(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]