The quotes are excellent. As are the rockets everywhere.
“Because it’s typically typed, rust() catches errors at compile time. [...] Also, it compiles code down to machine learning, allowing for extra efficiency.”
You mean the the reaction to jndi logging RCE for log4j has been way too seriously?
What's the basis of this assessment?
Logging library fetching remote code and inject to local application runtime. Seems a pretty bad idea for any people with decent amount of programming experience, right?
People are mad that someone created a Go library mocking the (obviously terrible) log4j behavior. How dare you make fun of the hardworking log4j developers, or the programming community that accepted their outrageously overcomplicated library without question? They're trying their best!
Honestly, I'm a bit miffed. It's a damned if you do, damned if you don't scenario for OSS.
Don't add feature X that other log library might add or has added, your lib is bad.
Add a feature X that other log library has, now you support it for the lifetime of universe. Oh and RCE might happen.
You added a feature that can load plugins and query any kind of data based on user provided strings, this is completely unexpected and never happened before. What to call it? How about SQL injection attack, sounds about fancy enough.
If you implement feature requests without thinking about the design and security implications it has you are doomed to repeat history.
Log4j maintainers didn't like the feature, they added it for backwards compatibility.
> Log4j maintainers have been working sleeplessly on mitigation measures; fixes, docs, CVE, replies to inquiries, etc. Yet nothing is stopping people to bash us, for work we aren't paid for, for a feature we all dislike yet needed to keep due to backward compatibility concerns.
It was added by these maintainers in 2.x and did not exist in 1.x. The maintainers are also different from 1.x developers and took the brand. They may regret their past decisions, but it was is irresponsible to claim that it was not their fault and added for backward compatibility.
There isn't a benefit to OSS projects all competing for the same audience and bloated feature set. Picking a subset, being opinionated about it and the implementation isn't wrong. For developers, there is such a thing as picking the right tool for the job, even if it isn't your favourite one you usually use.
Like if any other thing with automatic package management is any better.
.m2/repository is 5 gb on my machine.
Rust crates?
Go packages that are neatly tucked away too?
Node just makes it visible and in your face by putting the node_modules in you project directory.
Besides, what’s the alternative? Write stuff yourself? Put stuff in language stdlib? Even minimal service requires _a lot_ of things to do minimal stuff.
I think at some point (like introducing the ability to fetch resources off a network in your logging library) you need to step back and say "let's put this in its own, optional extra module".
Enterprise Java developers are scared to face the underlying human and cultural factors that led to such a massively boneheaded security vulnerability being possible.
Enterprise Java developers are ex-CORBA/DCOM/Smalltalk/Common Lisp developers actually, now busy building scalable Kubernetes clusters with Go to process CSV files with proper failover mechanisms.
First - JNDI is not logging library. I get that module can be named anything author wishes but it is too much after yesterdays "but why LDAP even in picture" comments... :) JNDI is just: java Naming and Directory Interface: https://docs.oracle.com/javase/tutorial/figures/jndi/jndiarc...
And all that log4fun is much more then one or two libraries bugs. Maybe even no or almoust no software bugs involwed ?
List of "features" in play :>
- log4j include realy rich log messages parser...
- not proper usage of logs formats
- log4j have ability to call to the network...
- Internet calls are allowed from backend facing service like logger...
- parsing "dot" have surprising effects - did't saw that in code, info after HN comments
- log4j have ability to ask any database including LDAP for configuration
- configuration have form of executable code :> .class WTF !!!
- Java have ability to load .class files at runtime, analogous to linker .so/.dll files. Except Java can do this for files from network. Buitl-in feature, pretty automatic :>
- security manager was off on JNDI, probably becouse naming services like directories for names and configurations are supoused to be internal and protected...
- no one use Java sacurity manager, at least it's very serious and enterprise-only black magic (voices in the internet: no! it's not so hard to use ! just some certs!)
- security manager is planned to be removed from Java anyway :)
- security bugs from years ago didn't realy fixed...
and last but no least:
- Minecraft servers are being hacked all over the world ! Chaos and panic ! :)
Something more ? :)
Now, do loading executables from network is standard enterprisy practice ? Getting .dll's or COMs from db ? I hear once from Sun employee about SQL queries
looked up from LDAP server. But it is Oracle now...
On the name: I knew jndi wasn't accurate (I read the 2016 blackhat slides) but the name I was going to use for the joke, log4g, was already in use and I didn't want to screw with their search results.
> - Minecraft servers are being hacked all over the world ! Chaos and panic ! :)
It sounded funny, but last night I was laying on my bed watching my last video of the day uploaded by a Minecraft YouTuber (xisumavoid actually) who mentioned the "Critical Security Issue". Back then my first reaction was "HA! suck on that Mojang!" without a single awareness of how bad things actual turned out.
I guess if you're a Java dev, subscribe to Minecraft news really helps (a little, maybe) LOL.
> - parsing "dot" have surprising effects - did't saw that in code, info after HN comments
This is fake. There are no "parsing dot have surprising effects" part in this bug. Actually there is no bug at all. All we have is a documented (though misleading) "hey you can call anything JNDI in your log message" INTENDED FEATURE.
Multiple people said they were able to trigger the RCE by supplying the syntax in question in log parameters, so the CVE is independent of whether people let users provide a format string or not (log.info("foo: %s", var) vs. log.info(var)).
log4j actually has something replacing an expression in curly brackets with something that can make a network call? And that just sat there?
From the look of it, it’s not just an edge case of jndi either, it seems it’s the purpose of the whole prefix?
When would a network request ever be a valid thing to do as a result of logging?
Not to mention, when would it ever be acceptable to run remote code as a result? Or was the execution of a remote class using a vulnerability and not by protocol design?
This was by design. Java has a history of these kinds of wild exploits ever since the XML days.
The original use case was probably something like: we want to be able to customise the logging on a per user/customer basis, so if we can make a call to our LDAP server, we can return a Java class that will implement that customisation.
This is definitely the kind of thing you'd get from an enterprise IT consultancy when you ask for an ERP system and require services to authenticate via ActiveDirectory.
It's easy to imagine a chain of changes, starting from innocuous string substitution with static strings in the code base and gradually building up to downright exploitable network access and multiple substitutions, all based on the previous changes as precedent (we already do substitutions, this is just one more).
That's not to say it shouldn't have been obvious, but string substitution using functions can have non-obvious impacts as functions call functions which are then modified later by someone else to do crazy things like network calls or parsing code for the sake of convenience.
You see the same in say rails templates which might fire off dozens of expensive sql queries to a database and without changing the template but just changing one of those methods on a model the entire performance profile can change - nobody is to blame exactly, but the entire system makes it easy to shoot yourself in the foot.
As far as I can tell they had some shared configuration for multiple web services exposed on jndi and wanted to refer to that in log4j directly instead of having to import it manually.
> From the look of it, it’s not just an edge case of jndi either, it seems it’s the purpose of the whole prefix?
The original purpose of JNDI, back in the "the network is the computer" days at Sun, was all about accessing remote objects without having to care about where they were located.
The current use of JNDI, however, is about accessing resources external to the current J2EE web application, but still within the same JVM instance. For instance, using the JNDI name "java:comp/env/jdbc/something" to access a database configured on the application server.
It's this last use which AFAIK was the motivation for adding that lookup to log4j: it allows adding some metadata about the current web application context to the log output. The original use of JNDI, to access remote resources, has mostly been forgotten, and could be considered a vestigial feature nowadays.
It probably went down as there is JNDI, a separate widely-used tool. Log4j wanted to add an option to log properties, like “Started logging ${app.name}”, for which they chose this approach. They just didn’t think through/didn’t know the reach of JNDI, but both things make sense separately.
We should not make fun of log4j2 developers for the work they're not paid for, they made it in their spare time. it's a shame so many companys are using log4j2 but few(if not none) sponsor them.
https://github.com/sponsors/rgoers
I almost stopped myself from posting it over such concerns, but I wasn't about to let all those minutes go to waste without sharing a joke to some. It was really just meant for Twitter banter.
I was just screwing around bored in transit while reading about all log4j substitution types.
This attitude is so peculiar and pernicious. As far as I can tell it's basically: when someone does something we find bad or wrong the only appropriate reaction is gratitude for their hard work and effort. Any other reaction could lead to them feeling bad.
That's bullshit. People make mistakes. People do malicious things under the guise of making a mistake and then hide behind this weirdly passive attitude.
People have been joking about left-pad any time they hear about nodejs. This isn't unexpected.
It could be because people want to rationalize their technology choices. Perhaps not all of them, some of us really like having a laugh for how broken the industry is :)
What I would be concerned with is this, before anything else:
import "github.com/bradfitz/jndi"
where is the version specified of what we are fetching? And at least a SHA256 to validate that it continues to be the same as what we fetched the first time, once upon a time?
Without this, a good, secure logging library can suddenly turn bad in between your rebuilds, and you don't know.
You probably want this piece to be cached locally, so your project builds even when the network or github is down.
The version is specified in the go.mod file. The checksum of the module at that version is saved in the go.sum file. And on initial download the module checksum is validated against a auditable checksum database to verify that it matches the expected value for that module and version.
What's the intention behind this repo? Seems to me the effort could have been better redirected towards fixing the insecure library instead. I'm not familiar with the Go ecosystem - is there some "Go more secure than Java" culture of mocking there?
> Seems to me the effort could have been better redirected towards fixing the insecure library instead.
It's already fixed and released with the fix.
I also like to steer away from this type of reasoning, because it's applicable to almost anything: why are you here commenting on HN when you could be helping with the fix or doing charity work?
I can only speak for me, but isolated demonstrations of security vulnerabilities have definitely helped me learn both how to anticipate and identify issues in real work. Jokes still work well for that purpose. Sure, it wasn’t a direct contribution to log4j but maybe it provides some reference material to someone building another library which could benefit from knowing the possible exploit.
That's the beauty of open source. Someone else did it for you. Now, you can use it without having to spend that hour. You should be thanking contributors to the open software community
It’s a demonstration in golang of what the vuln is. The assumption (not a bad one) is that golang devs may not be familiar with Java things and happenings. I can actually use it and simulate what an attacker could do. So it lets golang devs play with the problem.
The problem with this vuln is that since this library is a Java library that’s used everywhere, remediation is going to have a really long tail. There are a fuckton of apps that use this logger and it’s owners are not aware of it. Or it’s used in a part of a stack that’s not tracked yet… nobody can really tell.
