Technologist vs. spy: the xz backdoor debate | Hacker News Reader

Technologist vs. spy: the xz backdoor debate

lcamtuf.substack.com

63 pointsrbc23 comments

>In other words, all signs point to this being a professional, for-pay operation — and it wouldn’t be surprising if it was paid for by a foreign government.

Or a not-foreign government…

We just call them state actors

This is an interesting article. Zalewski is almost unique in the ability and credibility to write this. He used to work for Google in infosec, he's got a lot of experience writing code, and he no longer works for a big corporation, so he's free to say what he thinks.

More evidence that the OSS community needs to drop the “many eyes” theory of security

On the contrary.

This was detected before it reached major distributors. The only major one hit by this was homebrew, but they have never understood security anyway.

> The only major one hit by this was homebrew, but they have never understood security anyway.

MacOS doesn't ship with sshd running out of the box, and vanishingly few people ever enable it.

That's not the issue here. The xz backdoor author could have used the same technique to hijack any application that linked to xz, not just sshd.

> The only major one hit by this was homebrew, but they have never understood security anyway.

Do you have any evidence that other distros wouldn't have done the same? What measures do other distros have in place that would've stopped the inclusion of the backdoor had they not been alerted at the right time?

As opposed to? The buck has to stop at a human somewhere

I guess to me it suggested even more eyes would be even better.

would 5 eyes, 9 eyes and even 14 eyes be enough?

Not really replying to you…

The big difference is that everybody is able to see exactly what has changed recently by comparing old open source code to contemporary open source code.

This makes for a much smaller amount of content that needs to be reviewed by those eyes.

>The relationship with commercial vendors isn’t always healthy, but many major OSS projects are supported to a significant extent.

Almost always the so called "community" supporting a OSS project is an employee of a commercial vendor who is only interested as long as he is assigned to the project or task.

The solution is to have a full time owners and maintainers for all the critical projects and the government has to foot the bill. The govt can setup a division to identify such projects.

I'm amazed we have gotten this far without something like that happening. Critical infastructure is built ontop of this pile of software that is all being maintained by. If every major piece of infastructure (power plant, water treatment plant, etc) would dedicate 1 full time engineer to 1 open source dependency that they use, there would be more than enough man power to solve it.

We can't even support actual critical physical infrastructure anymore, like roads, bridges, and the power grid. And that stuff has very obvious immediate consequences when it breaks. Try explaining to your local octogenarian senator what xz is and why OpenSSH shouldn't just be funded by whatever spare change we find in the couch cushions.

Governments will just outsource it to commercial contractors at this point.

Government: launches a years-long covert operation to take over maintainership of critical project in order to insert a backdoor.

HN comments: the solution is for government to maintain these critical projects.

That's a likelihood it would seem.

I mean, getting an actual government agency with an appropriate mission specified by law _would_ help. Both from a recruiting point of view (you get sufficiently ideologically motivated people), but also from an accountability point of view. These agencies are ultimately responsible to someone. And the law has that nice property of knowing who and how to hurt those people. So yeah. Getting a (or the) government to maintain OSS infrastructure definitely would help. And probably also prevent this kind of thing as far, far too risky to attempt

>In fact, here’s an interesting thought: perhaps they have known for a while. Would we be able to tell the difference between a carefully-timed disclosure — presumably engineered to conceal “methods and sources” — and a serendipitous discovery?

All that can be avoided by doing really good sets of unit tests and integration tests, then incorporate its test result into the validation part of the repository.

The evergreen: "Keep doing what you're doing, except better this time"

Bonus points if the tests come complete with obfuscated binary (or near enough) blobs.

Reply on news.ycombinator.com