Jndi: An irresponsibly bad logging library | Hacker News Reader

Jndi: An irresponsibly bad logging library

github.com

206 pointschrissnell81 comments

Good satire. Code can be art too. Everyone here is taking this way too seriously.

Yeah I thought this was pretty funny. I AM trying to understand why people are so mad though.

Enterprise Java developers are scared to face the underlying human and cultural factors that led to such a massively boneheaded security vulnerability being possible.

Ahaha. Unfortunately they are not. As in they don't care enough to fear or face it.

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.

LOL this one got an audible chuckle out of me

Real Enterprise Java developer are probably still using log4j 1.x so are unaffected by the bug.

can confirm :D

Let’s inventory other such jokes.

Google Annotation Gallery, annotations for things which shouldn’t have been coded: https://code.google.com/archive/p/gag/

VanillaJS, the most used JS library with famous users such as Google, Apache and even the NASA itself. http://vanilla-js.com/

FizzBuzzEnterpriseEdition, the correct Java implementation of the interview question: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

FizzBuzzEnterpriseEdition and its issues are fucking gold.

Also hello-world.rs

https://github.com/mTvare6/hello-world.rs

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?

Or I missed something.

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!

I'm sure the log4j developers have just as much potential as the code they're sort of maintaining.

If you let them into your codebase you get federated remote code updates for free.

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.

It all starts with little changes.

Allow us to show colors in console...

Allow us more formatting options...

We need to display remotely added class...

We need JNDI access...

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".

There are ways to manage this sort of stuff.

> 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.

As much as people moan about npm community, it does give you many choices and you can avoid complicated massive libs

...By adding thousands of libs, turning node_modules into a multi GB folder. Oh, and each of which can be compromised by an unscrupulous actor.

Good luck auditing that.

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.

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.

log4gol is the project name no one needs, but that we deserve, or something

> - 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.

> - 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.

> - not proper usage of logs formats

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 enterprise level thinking.

Some history from cloudflare here: https://blog.cloudflare.com/inside-the-log4j2-vulnerability-...

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.

Never go full enterprise level thinking.

> This is enterprise level thinking.

An enterprise-level app must be like a slum built on a minefield, then.

More like a disco dance floor built on a minefield.

> 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?

Here is the ticket for it: https://issues.apache.org/jira/browse/LOG4J2-313

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.

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.

> 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.

This is great but I feel this needs a javascript interpreter. Like a VM, and every log entry could be stored on a blockchain with a stack machine.

    def log(input)
      puts eval(input)
    end

Here you go, so powerful, so great

I’ve always loathed login and its Python offspring logging for over engineering and enterprisey code stench, and now I can gloat.

s/login/log4j/g

Pesky autocorrect...

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

The project comes across as arrogant. Perhaps it's just me.

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.

For what it's worth, I didn't get this impression at all, I interpreted it as very amusing light-hearted humour

I don't understand the first commenter. Seems like just plain old fun. I love it.

I didn’t get a sense of arrogance at all. It feels like a gentle poking with love!

Those thinking Brad Fitzpatrick is arrogant to open source should look into Brad Fitzpatrick’s contribution to open source.

Could you explain that please? Why does it seem arrogant?

It’s important to keep a sense of humor and humility about working with logic machines from our squishy salt water meat brains.

There are only two kinds of programmers in this world. Those who don’t make anything, and those who create sev 10 global security nightmares.

This is actually a very friendly nudge... It only downloads and replaces the jndi escape sequence. No remote code execution.

This could be extended using https://pkg.go.dev/plugin

(Although, keeping it friendly is probably a good idea.)

I considered it but stopped myself before actually running the response body from the HTTP GET. Too much :)

I’ll be gloating about the next golang security issue

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 :)

I agree. All software is utter garbage.

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.

Do people really code like this?

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.

See: https://go.dev/ref/mod#authenticating

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?

Bradfitz is a pretty solid eng, and clearly doing this for fun.

No. This is just mocking.

I'm sure no library in <Insert language here> had scope creep that led to vulnerability.

I'm the author of the "mocking".

I prefer to call it coping. :)

I had a CVE against my own code just yesterday. It happens. I made fun of myself too:

https://twitter.com/bradfitz/status/1469015417679081472

Heh, go errori checking FTW!

Well you did choose your poison… ;)

It's just a joke and taking the piss out of the whole ordeal more than anything else.

> 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?

Trust me, what I'm doing right now isn't productive either.

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.

I wrote the repo. I preemptively apologized for the bad joke:

https://twitter.com/bradfitz/status/1469523009484431363 https://twitter.com/bradfitz/status/1469523985998118925

It started with me reading seeing this tweet:

https://twitter.com/_StaticFlow_/status/1469358229767475205

And I was just thinking it'd be fun to implement an expander for those. (https://twitter.com/bradfitz/status/1469526259335974912)

It's a good joke

Seems you are not familiar with Java either as the insecure log4j2 library is already fixed by volunteers.

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.

Its a joke. Its 100 lines total. Probably took an hour.

Why didn't you fix a bug with an open source library instead of writing this comment?

I wouldn't have wasted an hour on it. :)

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

I wrote this code. (note how my HN username matches the GitHub repo :))

I meant that it didn't take anywhere near an hour. (But I also didn't have a stopwatch out.)

gotcha. didn't follow the usernames. tried to be clever, fell on face. typical!

Reply on news.ycombinator.com