Backdoor in XZ Utils That Almost Happened
lawfaremedia.orgI find it unfortunate that Schneier chose to underline the XZ maintainer’s mental health issues (literally—he linkified it) as the reason he’d slowed down on the project, which then led to being open to taking on the malicious co-maintainer.
Schneier then follows that linkified fact up immediately with a parenthetical that Collin isn’t to blame. But then why call out that very potentially stigmatic thing at all, with sources to boot?
That explanatory note from Collin was buried in a mailing list and was at most a footnote to this story. Now it’s going to be part of the public accounting pushed by a famous security pundit with international reach, and with very little other context given to mitigate.
Either Schneier was trying to make a point of some kind, in which case he sure wheedled around it, or he should’ve been considerably more careful with essentially the only personal fact he chose to highlight about Collin. Either way, I’m disappointed.
Because the attackers successfully exploited it. And therefore it's something we need to prevent from happening again. The problem is there isn't an easy technical solution, this is is a social/medical issue that they exploited.
Slowdowns happen for all kinds of reasons. Life comes first. The explanation behind the slowdown wasn’t relevant here or a factor in the attack. They exploited the growing need for a co-maintainer. Airing the dude’s medical issues, particularly out of context to an unintended audience, isn’t awesome.
Ah, yes, the panacea for all mental health problems: brushing them under the rug and not talking about them.
Is everybody with mental health issues required to offer them up for public discussion at every opportunity?
His mental health wasn’t relevant to the attack from any report I’ve read. That makes it a bit odd and more than a little thoughtless to highlight it.
People slow down on projects for a ton of reasons. The guy could have been in chemo or had a kid. The result would be the same: he’d need a co-maintainer to keep the pace. The attackers would’ve capitalized on that. They’d plainly been waiting for whatever opportunity would work.
> The market economy rewards this sort of insecurity.
That's the money quote, right there. As long as people are willing to pay for shit, there will be people willing to produce and sell shit.
Why bother doing due diligence, if skipping it, means an extra lambo in the garage?
changing the code by one character making it have an int overflow would have been more elegant.... no and the reason I even bring this point up is in early days of hacking into developers machines sometimes you find unpublished integer overflow exploits...
Maybe, but xz wasn’t parsing any input in the SSH use-case so that wouldn’t have resulted in an SSH backdoor.
"Everything you use contains dozens of these libraries: some commercial, some open source and freely available."
"Everything". Really. I use numerous programs that do not "contain dozens of libraries".
How could he improve the sentence. Perhaps something like
"Many programs link to dozens of these libraries..."
"Everything most people use contains dozens of these libraries..."
And so on.
I am typing this comment in textmode using a text-only browser that is statically-linked to less than five libraries, including libc. I'm not using any commercial libraries. I have no idea what comprises "everything" anyone reading it is using or whether each of those things is linked to "dozens of libraries". How would I. And neither does this author.
How difficult is it for an author to verify the accuracy of each sentence in an article. Perhaps it is more difficult when you rely on software developers as sources and they tell you a story full of hyperbole, exaggeration and biased, selective disclosure of facts.
The article in japantimes.co.jp someone submitted was absolutely cringeworthy.
But if you substitute “libraries” for “software supply chain”, don’t you think it’s pretty close to still being true?
Libraries, SDKs, APIs, a framework, a language, a compiler/interpreter, a OS/kernel, testing framework, perf testing, debugger, IDE, version control system, hosting site, documentation site, etc.
Obviously, there are rare instances when there is a mostly standalone app (or some ecosystem that isn’t based on OSS), but those seem to be the rare exceptions, rather than the rule.