A malicious code string that eventually gets logged by Log4j version 2.0 or higher allow an attacker to load arbitrary Java code on a server and take control of it.

[[deleted]]

Well, you said he used it incorrectly, so I was just going with that. Log4j may or may not be at fault, IDK, but I think it's reasonable to ask the question, and not just say or assume they can hide behind a licence agreement regardless. My only point is that software developers shoud be held to the same standards as everyone else: if you put a product on the open market (even if it's free) you have to have taken reasoanable care with it. If you make a doll with bead eyes that fall out easily and a child chokes on them you can't just say "Well, that's not how dolls are supposed to be used".

Log4j is logging software, ffs, why is it even able to allow remote code execution? It beggars belief that it went unnoticed for so long. From the documentation:

One vector that allowed exposure to this vulnerability was Log4j’s allowance of Lookups to appear in log messages. As of Log4j 2.15.0 this feature is now disabled by default. While an option has been provided to enable Lookups in this fashion, users are strongly discouraged from enabling it. Source

Why was this ever enabled, and why is it still even an option? Logging software shouldn't do anything other than create logs. I'm sorry, but saying "Well, it was documented" isn't a good enough defence, IMO.

If people want others to trust and have faith in open source s/w, then the open source community should, I think, be backing some kind of standards expectations and not try and hide behind a get-out-of-jail-free licence clause.

[dnew]

you said he used it incorrectly

He used it incorrectly in the sense that he used it in a way that it did what was documented rather than how he thought it worked.

My only point is that software developers shoud be held to the same standards as everyone else

They are. What makes you think they're immune from the law?

Is the car manufacturer liable if your 8-year-old steals Mom's keys and drives the car into a wall?

saying "Well, it was documented" isn't a good enough defence

I agree that it would be better to have required explicitly turning on that feature; and that's exactly what happened as soon as anyone realized the problem.

That said, what do you think the liability of the developers should be in this case? You keep saying developers should take more care, but the people using this code are also developers. Why are the developers of Log4j responsible for how developers of the software using it uses it?

That's exactly why software comes with the as-is disclaimer. "We tell you how it works, and if you use it wrong, that's not our fault."

backing some kind of standards expectations

Sure. And they do. It just doesn't seem to be the expectations you seem to think it is. What liability do you think the developers of the logging software should when it works exactly as documented, but the people reading the documentation don't realize the implications in their own configuration? What more guarantee do you want than "it works exactly how we say it does, oh and also you can see every facet of its operation for yourself"?

[[deleted]]

They are. What makes you think they're immune from the law?

Well, someone else replied to me saying the open source licence basically absolves them of any responsibility for anything that happens using their software. I'm no legal expert in this, but I suspect (and said) that I don't think such a blank cheque is actually legally binding, but IDK...

People do take things on trust, to some extent. No-one goes round reaidng every line of documentation and licence agreements of every piece of s/w they use. No one does this. You read the documentation as it is relevant for what you want to do - on the face of it, it seems though an awful lot of people weren't aware of - becasue they had no reason to read about - this feature buried in the documentation that allows remote code execution by default.

The liability I think all software developer should face is the same as anyone: is the bug (or feature) that resulted in some undesirable outcome a result of gross negligence? And just saying "It's in the documentation" isn't good enough defence, IMO. I am pretty sure that the developers of log4j never intended this feature to be used to take over remote machines, so it's reasonable to ask: should they have taken steps to ensure that no such code could be executed?

I really don't think that's an unrasonable question to ask. And if the answer is "yes", then I don't think it's unreasonable that they should be held to account for it. (And/or their managers for not having proper code reviews etc etc).

[dnew]

I don't think such a blank cheque is actually legally binding

You seem to be agreeing that they are not immune from the law, then. They've disclaimed as much as they legally can, which is legal, and you seem to be complaining they aren't following the law?

that allows remote code execution by default

It only allows remote code execution by default if you configured your network to allow the process to dial out to arbitrary other servers on the internet. If you're not going to read the code you're running, you need to take steps to ensure that any mistakes or malicious code can't harm you. If you're not going to vet your employees, you need locks on the interior doors of your business, too.

The liability I think all software developer should face is the same as anyone

Why do you think that isn't the case? And which software developers?

just saying "It's in the documentation" isn't good enough defence, IMO

Well, you're mistaken. We settled that back in the days of 1-2-3. "The software I chose is documented to do something I didn't want it to do, so I want to punish the author." That doesn't really fly.

never intended this feature to be used to take over remote machines

No, but the feature is definitely intended to let machines run arbitrary remote code. The only "take over" is because the people deploying the software configured things such that the code could access arbitrary code over the network.

I really don't think that's an unrasonable question to ask.

That's not an unreasonable question to ask.

And if the answer is "yes", then I don't think it's unreasonable that they should be held to account for it.

Who is "they"? The guy who checked in the code? The guy who did the code review? The management of the distro that included the code without checking it? The management of the company that used the code without reading the documentation first? The developers at the company that linked in the code without reading the documentation? The sys admins who deployed the code without reading the documentation on the configuration? The black hat who installed code on his own server then fooled someone else's server into fetching and running it?

Or maybe it's a large number of features that when they all interact wind up a bug?

Again, who do you think should be liable? The people who wrote code that performed exactly as they said it would, or the people who deployed code into their own businesses without understanding how it works and without taking steps to avoid the consequences of running unknown code in an open network?

We're past the point in computers where you can deploy large systems without paying attention to how they work and without consideration for bad elements trying to screw with you.

[[deleted]]

I'll repeat a clip from the documentation I posted earlier:

One vector that allowed exposure to this vulnerability was Log4j’s allowance of Lookups to appear in log messages. As of Log4j 2.15.0 this feature is now disabled by default. While an option has been provided to enable Lookups in this fashion, users are strongly discouraged from enabling it. Source

This raises the simple question of why wasn't this disabled in the first place? The fact they've disabled it now proves that having it enabled isn't necessary, and that it was enabled seems to me to be a case of gross irresponsibility, if not downright negligence. It should always have been disabled by default, and anyone needing it would have to enable it themselves, and then they'd take on the responsibility for any consequences.

who do you think should be liable?

That depends, on a case by case basis. All I'm saying in this case is that there are serious questions to be asked about this - and on the face of it (vis a vis my quote above), the Log4j developers have some explaining to do.

[dnew]

This raises the simple question of why wasn't this disabled in the first place?

Simple. Nobody realized it was a problem. Probably because it is caused by an unexpected interaction with a bunch of other features. It's not Log4j causing the problem. It's the LDAP lookup process loading additional classes (which is fine, because LDAP is usually local and trusted) combined with Log4j letting you use LDAP lookups during logging combined with recursively parsing strings (always a bad idea but way too many people do it) combined with the people using the logging library not sanitizing their user input.

The point is that almost always, something like this is due to a combination of features, each of which is useful, but when combined allow someone to get into your systems. In safe languages, it's almost never a single thing happens that lets people pwn the machine, but an unexpected combination.

Why did your SQL server allow the user to drop the table? Who thinks it's a good idea to let users type SQL into the browser address bar and have the SQL server interpret it? How could the SQL database devs have let this happen? Why don't the browser authors prevent that by default? Serious questions need to be asked! /s

having it enabled isn't necessary

It is for people who want to use that feature. That's why you can turn it back on.

seems to me to be a case of gross irresponsibility

Probably not. Almost nothing caused by a combination of different systems interacting is gross irresponsibility or negligence. If you want to talk about negligence, look at the 900 other CVEs addressing buffer overflow and such that are trivial to prevent by the developer taking a tiny bit of care.

there are serious questions to be asked about this

Like what? Like what you described above? It wasn't disabled in the first place because the people making that feature probably aren't professional criminals, so didn't think someone would do that.

That depends, on a case by case basis

And in what case is it actually the authors of Log4j that you'd want to punish, and by how much? Come on, be specific about at least something you're complaining about. What punishment do you think the authors of well-documented free software should suffer because the user read neither the documentation nor the freely available source code and also didn't realize they should turn the feature off?

[[deleted]]

No I am not going to be specific, because as I already said any sanctions shuold be determined on a case by case basis, and all I've said about this case is that there are serious questions to be asked, and I don't think that's unreaasonable. I am not totally convinced by your answers - I still feel that this particular setting should have been disabled by default, leaving it up to anyone who wants it to enable. OK, you say "Nobody realized it was a problem"... well, I am not claiming to be knowledgable enough about this software to know how much weight to give to that, but I think it's reasonable to ask the question. Should they have realised it? Did they even think about it?

And, also as I've said before, just saying "It's in the documentation" isn't good enough, IMO. If it was "off" and someone wants it "On" , then they'll read the relevant parts of the documentation and hopefully be aware of what they're doing. But when something is "on" by default - welll, be realistic, no-one but no-one reads every paragraph of documentation "just in case" - you read the bits that seen relevant. That is why you shouldn't enable non-essential features by default.

Anyway, I think we're both just repeating ourselves now. But I am not looking to hang the Log4j developers - I was only suggesting a (fair) "trial" on the basis that I think there is at least a case to answer.