Maybe I can distract some people from vulnerable Java libraries. This funny cat walking across your tabs? It somehow ended up having pretty much the most severe vulnerability possible for a browser extension.
This seems to be a better list: https://github.com/NCSC-NL/log4shell/tree/main/software
For reference: that massive list of affected products is scary. #log4j
There I was smugly thinking: “Oh, I don’t use anything Java-based, no reason to care about that #log4j thing.” Wait, what? Ghidra? 🤦♂️
I’m off installing updates…
No, the crazy thing is that the most current Java version today still uses this clearly broken approach. It’s for backwards compatibility, you see?
Seriously, what kind of code could possibly depend on this broken equality concept? What justifies keeping this footgun around?
Similarly, identical URLs might be considered different if the host is associated with multiple IP addresses, so that the DNS request produces different results. While there is caching, results are only cached for a limited time.
But IMHO the crazy thing isn’t that they’ve done it like this. This approach was already in Java 1.0, so we are talking about 1996 or even earlier here. There was little understanding of real-world URL handling back then.
Yes, Java’s URL implementation has this weird concept of equality that depends on the results of DNS resolution. So different URLs will be considered equal (by means of .equals() and .hashCode()) if they resolve to the same IP address.
> I was today years old that I learned when you hash a URL in Java it does a DNS lookup to get the IP address associated with the hostname as part of the hash function.
Ah, ok, CCPA does not seem to apply. While accepting blog comments from California might be sufficient as “doing business in California,” I definitely do not meet any of the thresholds.
But I should probably check at some point whether CCPA has any provisions affecting my site that go beyond GDPR.
Mind you, this probably makes sense for logging patterns, adding context to logged data automatically. But resolving anything in the logged data is just 🤯 completely regardless of that vulnerability.
Tried to make sense of that log4j disaster. Apparently, somebody had the great idea for a logger to resolve variables in messages automatically, so that the code doing the logging doesn’t have to. The JNDI resolver then allowed loading Java classes dynamically, even remotely. 🙄
The amount of different output variants produced by WebPack and Browserify is staggering. Well, I guess I’ll keep adding them to my unwebpack script as I see them in the wild…
Third-party extensions without sandboxing? Turns out, Adobe applications still have that: extensions with unlimited access to the file system and ability to run executables. And the very first extension sample I looked at has an RCE vulnerability. Wow…
And I finally have the vulnerability acknowledged, with the fix expected to go live later today! 🥳
Wladimir Palant, software developer and security researcher, browser extensions expert. He/him
A Mastodon instance for info/cyber security-minded people.