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,
(1) coupled with
log4j implementing
(2) 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
(3) 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.
____
(1) The original was never designed to work with untrusted data.
(2) Neither anything in Java nor in JVM does that. It’s library’s own invention.
(3) Some exceptions exist due to language developers silently enforcing security on the programmers.