4 ms·

If I give you an rpm package, that isn't really any better. It can run any script during installation and you'll already be running it as root.

by aeyes 4y ago

TacticalCoder 4y ago
> If I give you an rpm package, that isn't really any better. It can run any script during installation and you'll already be running it as root. But it's not about you giving an rpm package at will. It's about the distro including packages in its official distribution and many people installing the very exact same package. Instead of people randomly pulling install scripts from the Web which can, for all we know, at every curl, be fetching a different install script. In addition to that Debian has an ever growing number of packages which are fully reproducible, bit for bit. All these executables, reproducible bit by bit. When I install a package from Debian I know many people have already both scrutinized it and installed it. It's not a guaranteed nothing shady is going on but what's safer: - installing a Debian package (moreover reproducible bit for bit) which many people already installed - curl bash'ing some URL at random Anyone who says the two offer the same guarantees is smoking something heavy. It's all too easy to sneak it in a backdoor for, say, once every 100 download when you moreover detect, as in TFA, that curl bash'ing is ongoing. And it's hard to catch. And it's near impossible to reproduce. When you install from a package that's full reproducible: there's nowhere to run, nowhere to hide, for the backdoor once noticed. It shall eventually be caught. Here's why it matters (FWIW there are tens of thousands of Debian packages which are fully reproducible): https://reproducible-builds.org/ https://reproducible-builds.org/ Thinking that installing a package "isn't really any better" than curl bash'ing from a URL is, plain simply, wrong.
colinsane 4y ago
consider the broader class of attack this article is demonstrating: stealthily delivering different payloads to different requests. i don’t know about rpm specifically, but most new-ish package managers do actually ensure this more strongly than any curl-based approach: a hash of the 3rd party content is provided through some more secure chain (e.g. directly in your OS’s or language’s package database, or signed by some key associated with one of those and which you’ve already trusted). yeah, if the package is delivered through the same channel as the bash script, and not anchored by anything external, you lose those benefits. but even hosting the package contents through pip or cargo or AUR or just unaffiliated and manually synced mirrors is a (relatively easy) way to decrease that attack surface.

If I give you an rpm package, that isn't really any better. It can run any script during installation and you'll already be running it as root.

by aeyes 4y ago

If I give you an rpm package, that isn't really any better. It can run any script during installation and you'll already be running it as root.

TacticalCoder 4y ago

> If I give you an rpm package, that isn't really any better. It can run any script during installation and you'll already be running it as root. But it's not about you giving an rpm package at will. It's about the distro including packages in its official distribution and many people installing the very exact same package. Instead of people randomly pulling install scripts from the Web which can, for all we know, at every curl, be fetching a different install script. In addition to that Debian has an ever growing number of packages which are fully reproducible, bit for bit. All these executables, reproducible bit by bit. When I install a package from Debian I know many people have already both scrutinized it and installed it. It's not a guaranteed nothing shady is going on but what's safer: - installing a Debian package (moreover reproducible bit for bit) which many people already installed - curl bash'ing some URL at random Anyone who says the two offer the same guarantees is smoking something heavy. It's all too easy to sneak it in a backdoor for, say, once every 100 download when you moreover detect, as in TFA, that curl bash'ing is ongoing. And it's hard to catch. And it's near impossible to reproduce. When you install from a package that's full reproducible: there's nowhere to run, nowhere to hide, for the backdoor once noticed. It shall eventually be caught. Here's why it matters (FWIW there are tens of thousands of Debian packages which are fully reproducible): https://reproducible-builds.org/ https://reproducible-builds.org/ Thinking that installing a package "isn't really any better" than curl bash'ing from a URL is, plain simply, wrong.

colinsane 4y ago

consider the broader class of attack this article is demonstrating: stealthily delivering different payloads to different requests. i don’t know about rpm specifically, but most new-ish package managers do actually ensure this more strongly than any curl-based approach: a hash of the 3rd party content is provided through some more secure chain (e.g. directly in your OS’s or language’s package database, or signed by some key associated with one of those and which you’ve already trusted). yeah, if the package is delivered through the same channel as the bash script, and not anchored by anything external, you lose those benefits. but even hosting the package contents through pip or cargo or AUR or just unaffiliated and manually synced mirrors is a (relatively easy) way to decrease that attack surface.