Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reflections on Distrusting xz

joeyh.name

Post reply on HN
Print view View original

241–250 of 335 posts

Re: Reflections on Distrusting xz

#241

Post by illiac786 »

acdha wrote: post #224
Gormo wrote: post #203

Earlier quoted context omitted.

It's not valid to regard the potential of negative consequences in any sphere of human life as a "national security risk". It's not valid to presume that the only way to mitigate risks is through top-down political intervention. And it's absolutely not valid to presume that making FOSS communities dependent on political subsidies would not have much worse and much longer term consequences than the problems we are try…

Your argument falls apart when you remember that the U.S. federal, state, and local governments are critically dependent on open source software – not just directly in things like Linux servers or Chrome/Edge/Firefox but also open source components used in appliances or compiled into commercial software. It is quite reasonable to argue that even a narrow approach of improving only components they run would be justifi…

I fail to see how you addressed the previous comment here. You ignored 80% of the points made.

Donations is fine, but it needs to be “no strings attached”, otherwise I agree with the GP that the risk of weaponising FOSS may become even greater.

I do agree that the US government is critically dependent on FOSS by now though. But “why throw money at it if it ain’t broken?” is the prevalent mentality, especially when everyone can have their own definition of “broken”…

Re: Reflections on Distrusting xz

#242

Post by galangalalgol »

mrspuratic wrote: post #182
galangalalgol wrote: post #90

Earlier quoted context omitted.

Agreed, as a developer: minimize your dependencies while providing your core function. Don't grant dependencies permissions they don't need. Be granular about it. Austral lets you select what filesystem, network, etc. access each library gets. Also, in big organizations, risk assessment is more about making sure there is someone to point the finger at, than actual security. Treating libfubar as golden because it ship…

"reduce the attack surface" is Security 101. Noting again that sshd doesn't natively use xz/liblzma (just libz) or systemd, so I don't think I need to point out where the billowing attack surface is ;) Apache (by way of mod_systemd) is similarly afflicted, as is rsyslogd, I guess most contemporary daemons that need systemd to play fair are (try: "fuser -v /lib64/liblzma.so.?" and maybe "ldd /lib64/libsystemd.so.?" to…

Yeah, its almost like "do one thing and do it well" had security benefits...

SElinux has the desired sort of granular permissions at the OS level, but if everything is dynamically linked to everything else that doesn't help as the tiniest lib is now part of every process and can hence pick and choose permissions.

But even if we go full monolith OS when systemd takes over the job of the kernel and the browser, that just changes where we need those permissions implemented. We can't practice zero trust when there is no mechanism for distrust in the system.

Re: Reflections on Distrusting xz

#243

Post by Gormo »

acdha wrote: post #224
Gormo wrote: post #203

Earlier quoted context omitted.

It's not valid to regard the potential of negative consequences in any sphere of human life as a "national security risk". It's not valid to presume that the only way to mitigate risks is through top-down political intervention. And it's absolutely not valid to presume that making FOSS communities dependent on political subsidies would not have much worse and much longer term consequences than the problems we are try…

Your argument falls apart when you remember that the U.S. federal, state, and local governments are critically dependent on open source software – not just directly in things like Linux servers or Chrome/Edge/Firefox but also open source components used in appliances or compiled into commercial software. It is quite reasonable to argue that even a narrow approach of improving only components they run would be justifi…

Organizations of all types -- government and otherwise -- are dependent on a wide variety of externally-sourced solutions for mission-critical operations. They can and do develop their own processes for testing and vetting potential solutions against their own criteria for performance, reliability, maintainability, and security.

Government orgs can and do contribute the results of the work they do in this regard upstream to FOSS projects. This has never not been the case, and when government-employed developers release the work they do to meet their own security requirements to the broader community, everyone benefits.

But this is drastically different from the scenario that the preceding poster was proposing, in which government officials would assume effective responsibility for the entire project, not just act as participants in the FOSS community.

That proposal would invert the situation, and change it from government devs adhering to the norms and conventions of the community to the community adhering to the rules and priorities defined by the government, which is where the negatives I outlined above would come into play.

Re: Reflections on Distrusting xz

#244

Post by saagarjha »

galangalalgol wrote: post #167
adql wrote: post #98

Earlier quoted context omitted.

> Agreed, as a developer: minimize your dependencies while providing your core function. Don't grant dependencies permissions they don't need. Be granular about it. Austral lets you select what filesystem, network, etc. access each library gets. Still wouldn't help for this particular exploit.

If systemd could deny liblzma any syacall or filesystem access, that would have prevented it. It is only used to compress a data stream, it only needs read access from one buffer, and write access to another. I realize there is no current mechanism for these granular permissions, that is what I was proposing be addressed.

We don't have the way to apply any restrictions on a per-library basis. This is generally quite difficult to do.

Re: Reflections on Distrusting xz

#245

Post by fullstop »

skywhopper wrote: post #5

my gut instinct is that xz needs to be rolled back to its pre-attack state, but obviously that would probably also reintroduce some bugs and likely break some things. Still, very curious to see some analysis on the impact of doing so, because this article points out, xz is in a critical path for lots of system level processes.

There were symbol changes in recent releases, and things like apt link to liblzma. If liblzma were downgraded without also updating apt at the same time you could be left with a non-functioning apt.

Re: Reflections on Distrusting xz

#246

Post by dboreham »

craftkiller wrote: post #123
Lichtso wrote: post #72

Earlier quoted context omitted.

Yes and no. A local GIT repo can be changed (including its history) however you please. But once you have shared it with others you can't take that back. If you try to, then others will notice that the hashes mismatch and that their HEAD diffs uncleanly. I know the term is infamous here, but GIT is essentially a blockchain. Each commit has a hash, which is based on the hashes of previous commits, forming a linked lis…

Its a Merkle Tree. They were invented 3 years before blockchains: https://en.wikipedia.org/wiki/Merkle_tree

Blockchains were invented in 1982?

Re: Reflections on Distrusting xz

#247

Post by Lichtso »

craftkiller wrote: post #123
Lichtso wrote: post #72

Earlier quoted context omitted.

Yes and no. A local GIT repo can be changed (including its history) however you please. But once you have shared it with others you can't take that back. If you try to, then others will notice that the hashes mismatch and that their HEAD diffs uncleanly. I know the term is infamous here, but GIT is essentially a blockchain. Each commit has a hash, which is based on the hashes of previous commits, forming a linked lis…

Its a Merkle Tree. They were invented 3 years before blockchains: https://en.wikipedia.org/wiki/Merkle_tree

It also uses a Merkle tree to compress the snapshot versions associated with commits. But the actual commit structure builds on top of that. A pure Merkle tree or forest would only give you a set of overlapping snapshots, without any directionality. So, I think it is fair to call it a blockchain as well.

Re: Reflections on Distrusting xz

#248

Post by Lichtso »

dboreham wrote: post #246
craftkiller wrote: post #123

Earlier quoted context omitted.

Its a Merkle Tree. They were invented 3 years before blockchains: https://en.wikipedia.org/wiki/Merkle_tree

Blockchains were invented in 1982?

In short, yes: https://en.wikipedia.org/wiki/Blockchain#History

People conflate blockchains, distributed networks and cryptocurrencies.

Re: Reflections on Distrusting xz

#249

Post by unethical_ban »

Gormo wrote: post #203
cletus wrote: post #170

The US spends $30-60 billion a year on agriculture and subisides [1]. This is controversial for all the obvious reasons. Without subsidies we'd waste less food but overproduction of food is an intentional objective of these programs. Why? Because if there's a major drought or crops are lost to ice or snow or flooding, Americans won't starve. It's why we have things like the US government having a reserve of over a bi…

It's not valid to regard the potential of negative consequences in any sphere of human life as a "national security risk". It's not valid to presume that the only way to mitigate risks is through top-down political intervention. And it's absolutely not valid to presume that making FOSS communities dependent on political subsidies would not have much worse and much longer term consequences than the problems we are try…

It's worth pointing out that we got lucky with a savvy tester stumbling on the backdoor in the dark. It wasn't anyone's job to find this backdoor, and arguably if it had been designed just a little better, no one would have noticed.

I wouldn't have gov't be maintainers of the main repos, but either be assigned to vetting critical repos, or mirroring them and co-maintaining copies endorsed for security (if I agreed gov't should be involved).

The ultimate questions is, are our critical systems (kernel, systemd, core userland) safe *enough* against future similar attacks, that we are okay trusting the global economy to another lucky valgrind test?

You incorrectly implied that a national security risk is "the potential of negative consequences in any sphere of human life". If we didn't get lucky, this could have been an economic and human catastrophe. That's not an inconvenience.

Re: Reflections on Distrusting xz

#250

Post by kzrdude »

rthnbgrredf wrote: post #188
kzrdude wrote: post #185

Earlier quoted context omitted.

Huge effort, because it is the default .deb compressor in Debian for example

Arch Linux has replaced it with zstd in 2020 already. It's doable for the next major release of Debian.

Certainly, but we need an xz decompressor to read the current debian repo versions for the next decades, when they are oldstable or archived.
Post reply on HN