>In particular, our code to parse .deb, .ar, .tar, and the HTTP signature verification code would strongly benefit from memory safe languages and a stronger approach to unit testing.
I can understand the importance of safe signature verification, but how is .deb parsing a problem? If you're installing a malicious package you've already lost. There's no need to exploit the parser when the user has already given you permission to modify arbitrary files.
It is possible the deb package is parsed to extract some metadata before being installed and before verifying signature.
Also there is aspect of defence in depth. Maybe you can compromise one package that itself can't do much, but installer runs with higher priviledges and has network access.
Another angle -- installed package may compromise one container, while a bug in apt can compromise the environment which provisions containers.
And then at some point there is "oh..." moment when the holes in different layers align nicely to make four "bad but not exploitable" bugs into a zero day shitshow
> It is possible the deb package is parsed to extract some metadata before being installed and before verifying signature.
Yes, .deb violates the cryptographic doom principle[1] (if you have to perform any cryptographic operation before verifying the message authentication code (or signature) on a message you’ve received, it will somehow inevitably lead to doom).
Their signed package formats (there are two) add extra sections to the `ar` archive for the signature, so they have to parse the archive metadata & extract the contents before validating the signature. This gives attackers a window to try to exploit this parsing & extraction code. Moving this to Rust will make attacks harder, but the root cause is a file format violating the cryptographic doom principle.
Sorry in advance if this is a dumb question, but isn't Rust's 'Cargo' package manager one of the draws of Rust? While I follow along that Rust's memory safety is a big benefit, does not the package manager and the supply chain attacks that come along with it take away from the benefits? For reference, NPM has had no shortage of supply chain security incidents.
How would adding Rust to such core dependencies not introduce new supply chain attack opportunities?
Cargo defaults to downloading from `crates.io` but can easily be configured to get its dependencies elsewhere. That could be an alternative registry run by a Linux distribution or other organization, or even just overriding paths to dependencies to where local copies are stored. I'd expect a distro like Debian to mandate the use of an internal crate registry which mirrors the crates they're choosing to include in the distro with the versions they're choosing. This adds supply chain attack opportunities in the same way that adding any software adds supply chain attack opportunities, the use of `cargo` instead of `curl` to download sources doesn't change anything here.
It's not cryptographic doom principle, as they don't decrypt before verifying signature, they just parse. It's still kinda sorta bad, but in a different way.
The parser can run before the user is asked for permission to make changes. The parsed metadata can then discourage the user from installing the package (e.g. because of extremely questionable dependencies).
Dependencies are probably in the apt database and do not need parsing, but not everything is, or perhaps apt can install arbitrary .deb files now?
Preferably one is not able to pwn a package repository by uploading single malicious .deb file to it. e.g. people on Ubuntu frequently use PPAs (private package archives). You can run your own on Launchpad. If you upload malicious package, it should not destroy Launchpad.
>In particular, our code to parse .deb, .ar, .tar, and the HTTP signature verification code would strongly benefit from memory safe languages and a stronger approach to unit testing.
I can understand the importance of safe signature verification, but how is .deb parsing a problem? If you're installing a malicious package you've already lost. There's no need to exploit the parser when the user has already given you permission to modify arbitrary files.