Log4j CVE-2021-44228

[madires]

Security warning: New zero-day in the Log4j Java library is already being exploited: https://www.zdnet.com/article/security-warning-new-zero-day-in-the-log4j-java-library-is-already-being-exploited/

Log4j is a Java library for logging and it's used by many Java programs. Tons of stuff are affected by this: https://github.com/YfryTchsGD/Log4jAttackSurface

[magic]

And the relevance of J*va is what exactly?

[madires]

You'll be suprised how many services, platforms or products are affected, e.g. iCloud, Ubiquity management tool or several Cisco products.

[magic]

I'm not surprised.
Friends don't let friends use software

[Ranayna]

That thing is nasty. *Very* nasty.

And it potentially affects anything that you can talk to in any way.

And, as often with such nasty security issues, in hindsight it is patently stupid and ridiculous that whoever wrote the software though that the problematic feature was ever a good idea.

To clarify a bit on the issue:
Java has a feature allowing the loading of code fragments on the fly. This can happen from *any* URL though. So it can be on you local machine, or it can also be code that is lying on some host in the internet. So far, so worrying
The issue that log4j has, is that when it logs something that matches the proper syntax, it actually goes ahead and loads the code it finds there! So, for example, if you have an application that uses log4j2 to log usernames on failed logins, you are vulnerable. Someone can simply use the offending string as username, try to log in, and bam, you are infected.
And you not only can load stuff from any URL, you can also directly inject Java code, but then might hit length limits.

So this is a really critical flaw. You have to patch it urgently, for anything reachable from the general internet. If you have not yet patched and you are vulnerable, it might already be too late.
There are running attacks on this vulnerability. There are reports of successful attacks.

[BradC]

All of our web services have been getting slammed with exploit attempts since the 10th.

[PKTKS]

And the relevance of J*va is what exactly?

Uncle GOOO  marvelous piece of advert A N D R O I D IIIIII

Must read on issue refer
https://christine.website/blog/open-source-broken-2021-12-11

Paul

[golden_labels]

And the relevance of J*va is what exactly?

Seeing how much attention the bug has received and the list of affected products and services, you should already know it is used widely. But that is underestimation, because the number of potential victims is much smaller than it could be. The problem has been patched about three years ago on Java’s side, while log4j added a configuration option to disable that type of behavior four years ago. There is a modification of the original exploit that circumvents the mitigations in Java, but it also imposes additional requirements with regard to the target system.

But, considering that your post is unlikely an actual question and rather bashing of the technology, some clarification may be useful. This vulnerability is not related to the library being written specifically in Java.

That’s a standard code injection attack of algorithmic nature, an effect of an oversight while reusing code,⁽¹⁾ coupled with log4j implementing⁽²⁾ a feature of using data sources localized on external servers. In other words: someone thought it will be a great idea for a message formatter to be able to obtain remote objects and for that purpose employed code never meant to work with potentially malicious data.

While CVE-2021-4428 relies on JVM’s feature, the part of that feature opening this vulnerability is not specific to Java. Any environment, that allows runtime code inclusion from attacker-controlled sources, is offering that attack path. The insecure code reuse problem is nothing to hold against log2j maintainers either, as it’s a plague in software — the reason NoScript blocks downloading of typefaces, why user-generated media are either banned or rewritten by many communication platforms, and until late 2010s the most widely used malware deployment vector (say hello to Adobe).

So, instead of mindlessly bashing something, maybe try understanding the nature of the problem? Because, if you are developing any serious software, it likely already contains 2/3 of that vulnerability and nearly⁽³⁾ certainly one of three factors listed above.

If you ask why such a supposedly common problem receives that level of attention, while others of its kind do not, it’s because this particular instance fulfills all of the following criteria: it’s an RCE, writing an exploit is trivial, the attack is not probabilistic, at its disclosure many high-profile targets were affected, it may be exploited in a way that easily circumvents firewalls, IDSs and WAFs, it may be executed in a manner that leaves absolutely no traces, its simple modification permits exfiltration of some types of data without even deploying code to the victim and actual attacks are being already observed. That’s not something that occurs every day.

Uncle GOOO  marvelous piece of advert A N D R O I D IIIIII

Android is not supporting Java. It uses a language with syntax based on old Java versions and offers similar APIs. In particular it misses both the ability to execute Java bytecode and JNDI, which are used in that vulnerability.

____
⁽¹⁾ The original was never designed to work with untrusted data.
⁽²⁾ Neither anything in Java nor in JVM does that. It’s library’s own invention.
⁽³⁾ Some exceptions exist due to language developers silently enforcing security on the programmers.

[magic]

But, considering that your post is unlikely an actual question and rather bashing of the technology, some clarification may be useful. This vulnerability is not related to the library being written specifically in Java.

No, I was surprised that anyone here would care about a J*va dumpster fire.
But "seeing the list of affected products and services" I realized that maybe more people use junk that I wouldn't touch with a 3 meter pole.

The insecure code reuse problem is nothing to hold against log2j maintainers either, as it’s a plague in software

Nothing is ever the fault of software developers, it's just the way software needs to be.
You are a software dev, right?

So, instead of mindlessly bashing something, maybe try understanding the nature of the problem? Because, if you are developing any serious software, it likely already contains 2/3 of that vulnerability and nearly⁽³⁾ certainly one of three factors listed above.

I understand the nature of the problem to be the "Arduino culture" of software development, i.e. taking a bunch of fresh-outta-college code monkeys to stich shit together from random libraries, frameworks and solutions ill-suited to the job.
I frankly don't care about understanding the J*va "ecosystem" or how this particular trainwreck unfolded. I have heard enough from those people to stay awy from them.

[PKTKS]

(..)
I understand the nature of the problem to be the "Arduino culture" of software development, i.e. taking a bunch of fresh-outta-college code monkeys to stich shit together from random libraries, frameworks and solutions ill-suited to the job.
I frankly don't care about understanding the J*va "ecosystem" or how this particular trainwreck unfolded. I have heard enough from those people to stay awy from them.

Cheap expendable code-monkeys taken from a crowd of fresh newbies...
is and was the absolute method to have high profit margins from all
the MAJORS tech dinosaurs as of today (fill the names yourself)

Quoting a very good assertion...

discusses a pertinent problem that has plagued the FOSS (Free and Open Source) world ever since large for-profit corporations started their widespread consumption of FOSS, ever since countless unicorns raised infinite amounts of funding on valuations built pretty much entirely on FOSS, ever since FOSS got co-opted into corporatisation and capitalisation. And yet, countless maintainers of critical and widely used FOSS struggle to make a living.


JAVA  was (since day ONE)  sold as a SILVER BULLET that would solve
all computer security hazards and mitigations..  the very same way
they are pushing RUST as the SILVER BULLET to everything security...

Guess what.. who owns GIT today?
Who benefits of expendable fresh code monkeys writing shit in JAVA PYTHING and  etc et al ?
Who really hire senior grade devels?

WTF anyone expect to happen now w/the new CLOUD rent_your_life shit?

Things will just get worse and while they can deprecate a whole system
every 15 days ... share holders are happy ... until the shit hit the fan..

This the JAVA - almost a whole fucking OS itself..
May be you can call it by other names..
still the very same old shit..

Paul

[Jeroen3]

You'll be suprised how many services, platforms or products are affected, e.g. iCloud, Ubiquity management tool or several Cisco products.

3 Billion devices run java.

[madires]

The funny part of CVE-2021-44228 is that it's actually a Java feature (JNDI variable expansion) which simply does what it's intended for.

[magic]

Well, somebody also needs to decide to feed malicious data into that helpful language facility.

Reminds me of the good old times exploiting PHP inclusion bugs.
All I have ever known about PHP programming came from that

[ve7xen]

But, considering that your post is unlikely an actual question and rather bashing of the technology, some clarification may be useful. This vulnerability is not related to the library being written specifically in Java.

No, I was surprised that anyone here would care about a J*va dumpster fire.
But "seeing the list of affected products and services" I realized that maybe more people use junk that I wouldn't touch with a 3 meter pole.

The insecure code reuse problem is nothing to hold against log2j maintainers either, as it’s a plague in software

Nothing is ever the fault of software developers, it's just the way software needs to be.
You are a software dev, right?

So, instead of mindlessly bashing something, maybe try understanding the nature of the problem? Because, if you are developing any serious software, it likely already contains 2/3 of that vulnerability and nearly⁽³⁾ certainly one of three factors listed above.

I understand the nature of the problem to be the "Arduino culture" of software development, i.e. taking a bunch of fresh-outta-college code monkeys to stich shit together from random libraries, frameworks and solutions ill-suited to the job.
I frankly don't care about understanding the J*va "ecosystem" or how this particular trainwreck unfolded. I have heard enough from those people to stay awy from them.

Then why are you here, commenting on it, clearly having no idea what you are talking about - and even being proud of it - arrogantly disparaging developers using one of the most widely used and capable languages in the industry...? There is nothing wrong with Java, and this vulnerability has nothing to do with Java. The same pattern has occurred in countless vulnerabilities in every language in existence.

Not wanting to understand that this really has nothing to do with Java and is a common pattern of such security vulnerabilities in any language is a great way to make the same mistakes in your own products, and considering your attitude here, I am certain that you would walk right into many common pitfalls with your arrogance.

[SiliconWizard]

And the relevance of J*va is what exactly?

Too much unfortunately.

[magic]

Nothing to do with J*va, except somebody thought it would be a great idea if the JVM / standard library / whatever automatically fetched required class definitions from network locations embedded in deserialized objects (which is my vague understanding of how this exploit works).
Such a wonderful idea that they even turned it on by default for everybody for a few years.
And surely it was documented so well that every programmer knew about it.
 

Nothing, nothing is ever the fault of software developers.

And you see, there is actually a solid reason for that, because - gotcha - no single person is responsible for this bug.
How could the language designer foresee that somebody may deserialize a malicious object?
How could the library writer anticipate that somebody may log an untrusted string?
How could the application developer imagine that passing untrusted strings to 3rd party libraries with no warranty whatsoever may go wrong?
How could the management know that their developers copy-paste together random open source libraries and StackOverflow snippets?

The same pattern has occurred in countless vulnerabilities in every language in existence.

No, not the same.
C gives you plenty of rope to hang yourself, but not this particular noose.
Single-line remote loading of code is a job of richly featured, Web-enabled languages like PHP and now also Java, apparently
I doubt that even C# has ever had the same problem.
In every sane language you would have to implement this yourself, even if merely by chaining together networking and serialization functions from standard libraries.

[ve7xen]

Nothing to do with J*va, except somebody thought it would be a great idea if the JVM / standard library / whatever automatically fetched required class definitions from network locations embedded in deserialized objects (which is my vague understanding of how this exploit works).

It's not part of the standard library.

In every sane language you would have to implement this yourself, even if merely by chaining together networking and serialization functions from standard libraries.

The fact that a library included the kitchen sink is not a Java problem. It's not caused by Java, nor is it exclusively the domain of Java. In fact, it has absolutely nothing to do with Java at all. It was indeed a bad idea, but the fact that it was implemented in Java is merely a curiosity. If you think other languages are somehow immune to third-party libraries making poor design decisions, you have no idea what you're talking about.

C gives you plenty of rope to hang yourself, but not this particular noose.

The noose of passing user input to library functions whose behaviour you don't understand and is dangerous by default is language agnostic. And C has rather a lot of 'dangerous by default' standard library functions.

[magic]

JVM / standard library / whatever

It's not part of the standard library.

So it is part of whatever, then

The JNDI is included in the Java 2 SDK, v1.3 and later releases.
JNDI is included in the Java SE Platform.
Java Platform, Standard Edition (Java SE) lets you develop and deploy Java applications on desktops and servers.

IOW it's part of a quarter gigabyte package of libraries curated by Sun/Oracle which appears to be the only official way of getting the development tools from them and which you can then take for granted because it's easy enough to tell your customers to just download the same package and that's what everybody ends up doing, save for embedded or desktop applications which can get by with the JRE.

That's how the JNDI spread and that's why everybody is affected by it. They all installed the same packages, frameworks, "technologies" and "solutions" because J*va is not a programming language - it's a way of life and an answer to every question of existence. That's how it's marketed and that's how it's distributed to end users.

[madires]

Bonus time! If you think you've fixed your application using the updated Log4j version you might be wrong: CVE-2021-45046 (https://nvd.nist.gov/vuln/detail/CVE-2021-45046).

[golden_labels]

Ignorance feels good; ignorance mixed with overconfidence is a hard drug.

There is as much value in fighting either fanboys or bashers as it is in trying to discuss philosophy with a drunken person barely able to recall their name. The thing worth doing may be correcting misinformation before it infects other people. But that has been done above, so save yourself from xkcd 386.

To clarify one new statement from another person:
The exposure of JNDI in log4j isn’t itself the discussed vulnerability. It was an intentional feature of the library, and it had to be explicitly implemented and offered by log4j to be available. Accessing it isn’t magical: it is being directly given to be used. The vulnerability comes from assuming the formatting string can’t be controlled by the adversary. The researchers discovered it can. The situation is akin to that of C’s builtin printf being a route to RCE, data exfiltration or DoS; with the step making possible being like what bash has in its arithmetic evaluation if the adversary can control values.

2021-45046 is a mere DoS⁽¹⁾ and it’s expected to see those popping up. After any vulnerability getting famous, people start poking around or even modify the original finding to squeeze as much as possible from it. Which is why paying more attention to own products and services is a good idea: they are under higher risk for a few more months.
____
⁽¹⁾ Don’t interpret it as me being dismissive about it, but relatively to the original it’s hardly of any importance.

[ve7xen]

  JNDI is not the problem, loading remote objects is practically its entire, totally reasonable, purpose as an API. The problem is exclusively in log4j (NOT anything from Oracle or part of Java core, SE, or EE), which unexpectedly allowed what is a normal pattern for safe use of user input to give access to JNDI, which makes it unsafe.

The key, and very galling, problem here is that substitution in the log string is recursive by design. In a sane library, if you include user data via a format string, that variable is placed in the output string verbatim, and it will be safe since nothing in the user input causes side effects - it's merely placed as string. In log4j, that variable can itself contain its own substitutions, which will also be evaluated. This is just fucking braindead and surprising, so I assume developers did not expect this behaviour, which is why this problem is so widespread. log("{}", userAgent) is a reasonable thing to expect to be safe; log4j badly breaks the principle of least surprise here.

Variable replacement works in a recursive way. Thus, if a variable value contains a variable then that variable will also be replaced. Cyclic replacements are detected and will cause an exception to be thrown.

https://logging.apache.org/log4j/2.x/log4j-core/apidocs/org/apache/logging/log4j/core/lookup/StrSubstitutor.html

The possibility of RCE via JNDI was presumably also an oversight when it was added to log4j, but is a much more understandable thing to miss than the idea of allowing recursive string substitution which is just . Without that, only 'bad' code patterns that pass user data directly as format string would be susceptible (log(userAgent)), and this should be avoided anyway.

[magic]

If it just downloaded remote objects that wouldn't be easily exploitable for RCE if at all, I don't think there are stack overruns in JVM, but it downloads remote class definitions in order to construct completely alien types of objects.
And not even in the context of an established connection to a known database, like say an ORM would do, but it will happily establish new connection on per-object basis as directed by a single string.
Much more risky than anything I have seen commonly done.

Coming from the world of compiled languages, it feels like having a nice API to fetch DLLs from the Internet and using it as a matter of routine.
I mean, whatever works for them

Quick search shows it's not the first time there are RCEs due to this wonder API
https://www.veracode.com/blog/research/exploiting-jndi-injections-java

[ve7xen]

Serialization/marshalling of objects in any language commonly comes with the possibility of code execution, and most put big flashing red warnings about it in the documentation. It shouldn't ever be used anywhere near arbitrary user input, which is the intersection that log4j creates, and where the problem arises.

I agree that JNDI represents a bit of an antiquated paradigm, but it's not fundamentally a problem here. If you don't need it, don't load it and don't use it, and your application won't be vulnerable, no problem. In a similar way that sprintf is dangerous, and still present, but nobody competent uses it. The problem is that log4j both included JNDI functionality without obviously calling out the potential danger to its users, and critically, implemented it in a way that exposed that functionality via unsanitized input by default, with even best practice uses being vulnerable (I don't even think there is a way to avoid the recursive expansion...).

I think including JNDI functionality in a log library was clearly stupid, but it likely was proposed by a user, possibly along with a patch, and implemented without much thought as to its potential security impact. Happens all the time, even though it shouldn't. To me the more egregious thing is the recursive expansion *by design*. I can't imagine why you would want that or think it is a good idea.

[madires]

Log4Shell attacks expand to nation-state groups from China, Iran, North Korea, and Turkey: https://therecord.media/log4shell-attacks-expand-to-nation-state-groups-from-china-iran-north-korea-and-turkey/

Everyone tries to get a foot in the door at their prefered targets. Fun times!

[SiliconWizard]

Very funny actually.

And all that for logging stuff that is USELESS 99.9% of the time. Sure worth the pain! (Not saying you should never log anything, nor that such a crippled library is acceptable software, but just a note on the whole situation which is absurd IMHO.)