That log4j RCE is some fucking nasty business!!! Its exploits have already been observed multiple times in our company scope.

Time for some unplanned Saturday evening hot-patches :/

P.S. Why the fuck leave such a feature enabled as default??? I mean really, whose brilliant idea was "let's leave the message parser enabled as well as the LDAP query hooks... BY FUCKING DEFAULT!!!"

I mean really, is anyone using that? ANYONE?

And then they laugh at me when I say "stay away from frameworks", "use as little libraries as possible", "avoid foreign code in your codebase",...

you know what.... JOKE'S ON YOU!

https://devrant.com/rants/4993004/...

Redirecting you here if you have time to spare.

Just to add a minor detail.... Logging frameworks are a blessing.

I don't want to get angrier as I already am... But this is a primarily fault of devs. Yes, it can be misused - but it's a mistake that any service can take any unvalidated input and make it magically secure.

That's impossible. The RCE isn't the root of the problem, it's definitely the programmer.

@IntrusionCM It's not an either/or situation. Yes, devs are at fault for not sanitizing their input. However, there is still plenty of blame left to throw at log4j for having this feature in the first place and, worse, for having it enabled by default. That's the great thing about blame, there is always plenty to go around.

@NotJeckel

Ok.

Next time you read an user agreement license, an end user agreement or sth legislative like that - think of your statement.

You click ok. And you're done.

Did you read what they defaulted to? Highly doubt it.

Did you understand what you signed?
Even more doubt it.

You're expecting people to do good and right choices for you. This will never be a true statement. Especially if time is involved, cause over time a lot of things change.

@IntrusionCM I'm low on caffeine, so maybe I'm missing or misunderstanding your point.

Yes, the devs were assuming that log4j would do what was good and right for them, but it wasn't doing that. Log4j was wrong for that, but the devs were also wrong for making the assumption. Neither party is completely free of blame.

Handling copyright and digital legal matters is part of my job and I read ToSs and EULAs for fun. You should never trust that a ToS or EULA is trying to do anything good or right by you. They are never trying to help the user.

@NotJeckel Yes.

And that's exactly my point.

You're expecting sth to work in a certain way - biased that it works in a good way, providing sane defaults, being secure.

The same way usually treat EULAs or license agreements.

Every person knows that a EULA is a _contract_ between two parties that might be detrimental for one part - which is why we should read the EULA.

We see this on a day to day basis in our clients. We tell them "Don't push that red button" and they push it like it's their fucking G spot.

My point is: We Devs should never expect other Devs to be nice persons providing us with sane and secure defaults.

They're humans. They make mistakes. They are "faulty"… maybe greedy, maybe narcisstic, maybe psychopaths.

You're talking about blame. And that the devs who wrote Log4J are at blame.

My point is: Every dev who used Log4J is at blame. Using Log4J was a choice. Using any library is a choice.

It's a choice made by the dev.
And as any choice - it has consequences. We're biased and somehow we expect good outcome from choosing a library - but this - this positive bias - is exactly the fault that makes security holes so bad.

We talk about how FAANG is bad. We talk about how everything is bad.

Yet when we chose a library or knew we must use this library for whatever reason - we try to share blame and say it's their fault.

When it was our choice to use that library.

And when it was our fault not to secure that library.

Or not to ask the question why the defaults are insanely insecure.

I'm not saying they're not at fault - I'm saying that the blame should be largely at us devs who choose that library (even as a transitive dependency) and didn't think about the consequences.

It's easy to say it's the developers fault who wrote said feature or who made that bug.

But it's more important to ask why noone else has criticized this behaviour, changed the defaults or boycotted the library for it's insecure defaults.

@IntrusionCM Ah, I see what you're saying and I agree that the devs using log4j are to blame.

But the devs that made log4j also made bad choices, a logging library shouldn't execute strings as code, it's outside the concerns of that library. As a dev that builds libraries, that was a boneheaded choice and they should be called out on it. That functionality also shouldn't be on by default, that is bad library design and they deserve to be called out on it.

By all means, call out the devs that used log4j wrong, they deserve it, but don't let the log4j devs off easy, they also screwed up.

As I originally said, there is plenty of blame to go around here, pretty much everyone made by choices.

@NotJeckel YES.

Absolutely agree.

That should happened ages ago.

I don't exempt myself from being guilty - cause that behaviour was known for years.

But we really need a shift in the mentality of devs to prevent such things in the feature.

We should call out such mistakes. If we _knew_ this is stupid, we should change it or advocate for better defaults.

When we use such libraries despite their obvious security flaws, I think the fault lies more on our side.

Again - if it's an obscure thing or sth. that requires an full code audit, I wouldn't play the blame game.

But the behaviour that caused the RCE isn't an bug per se - it's a well known, documented and existing feature for years.

@IntrusionCM do you have a link where this is documented? I'd like to check if the docs say that all logger params participate in interpolation (unintuitive, insecure) or just the first one (intuitive, secure), or docs to not make the distinction (insecure, unintuitive, poorly documented)

Isn't this kinda fixed by having an up to date Java (like after 8u191 or something don't remember exactly)?

@ilikeglue no. The rce still exists. Having newer jre only eliminates a single attack vector. There are more vectors available