After repeatedly suffering issues with scam apps making it onto the Snap Store, Canonical maker of Ubuntu Linux have now decided to manually look over submissions.
That is a very good question. At this point, a hash function in the SHA-2 family is generally considered secure.
MD5 has been known to be cryptographically insecure since about 2008. Collisions can be reliably reached in sub-second timeframes on hardware that is over a decade old. It also has many other attack vectors. The only place that it really could reasonably be used is when checking for file integrity for an rsync or the like but even then, with modern hardware, there’s little reason to not use a secure hashing algorithm.
For SHA-1, successful collisions were hit in under 2^69 ops as early as 2005.
In 2017, Big G (when they were still trying but to be evil) announced the SHAttered attack that that reliably reached collisions with 2^63.1 ops. SHAttered required 6500 CPU-years and 110 GPU-years to implement but that’s a number well within reach for a well-funded adversary. Several other attacks from other directions have been proven out with the barrier to entry getting significantly lower. It doesn’t even take a state actor anymore with costs being estimated as low as $45k USD in 2020.
SHA-2 has not yet had any publicly disclosed success in defeating all hashing rounds. Last year, there was success in collision in 31/60 rounds for SHA-256 and 31/80 rounds for SHA-512. So, it’s generally thought to still be secure (noone has had yet disclosed a practical collision or pseudo collusion that is close to defeating ALL rounds).
EDIT: Newlines to avoid formatting (how do I escape formatting characters?)
The use of MD5 becomes a bigger issue when paired with the lack of package signatures. You can inject code into a package and find a colliding digest absurdly fast. I and a friend from Threatlocker created a Metasploit module to use Deb packages for local privesc based on the concept. If it touches the filesystem outside of the APT cache it becomes a vector.
In theory (whitepaper is still being written), if you MITM the connection to the APT mirror it’s using you can also carry out the attack over the network by injecting it into the package on the fly. Cert pinning might be a blocker, but local (LAN) package mirrors might still be valid attack targets. Enterprises often use MITM certs for things like DLP and packet inspection we might be able to leverage at least.
Yeah. This is a pretty big issue. Proper handling of MitM certs via a trusted root CA on the enterprise machines could mitigate a bit by avoiding use of TLS skip-verify but, there’s still a wider threat surface than there should be due to the use of MD5. Sub-second collisions means that malicious code could be readily inserted by an adversary through something like that xz backdoor and likely go unnoticed for much longer.
To save you some effort, they do not consider it a priority to fix. Code was attempted to merge that would make package signatures the default, but it was removed because it “was a waste of cpu cycles” when “md5 and the https was just as good”. I’m not kidding, you can find the whole conversation in the Debian mailing archives. So instead I’m going to make it known how dumb it is, and encourage people to use something else.
And MD5 for package integrity checking, and not using per-package PKI signatures.
That anyone still uses MD5 or SHA1 is unbelievable.
What should be used instead?
That is a very good question. At this point, a hash function in the SHA-2 family is generally considered secure.
MD5 has been known to be cryptographically insecure since about 2008. Collisions can be reliably reached in sub-second timeframes on hardware that is over a decade old. It also has many other attack vectors. The only place that it really could reasonably be used is when checking for file integrity for an rsync or the like but even then, with modern hardware, there’s little reason to not use a secure hashing algorithm.
For SHA-1, successful collisions were hit in under 2^69 ops as early as 2005.
In 2017, Big G (when they were still trying but to be evil) announced the SHAttered attack that that reliably reached collisions with 2^63.1 ops. SHAttered required 6500 CPU-years and 110 GPU-years to implement but that’s a number well within reach for a well-funded adversary. Several other attacks from other directions have been proven out with the barrier to entry getting significantly lower. It doesn’t even take a state actor anymore with costs being estimated as low as $45k USD in 2020.
SHA-2 has not yet had any publicly disclosed success in defeating all hashing rounds. Last year, there was success in collision in 31/60 rounds for SHA-256 and 31/80 rounds for SHA-512. So, it’s generally thought to still be secure (noone has had yet disclosed a practical collision or pseudo collusion that is close to defeating ALL rounds).
EDIT: Newlines to avoid formatting (how do I escape formatting characters?)
The use of MD5 becomes a bigger issue when paired with the lack of package signatures. You can inject code into a package and find a colliding digest absurdly fast. I and a friend from Threatlocker created a Metasploit module to use Deb packages for local privesc based on the concept. If it touches the filesystem outside of the APT cache it becomes a vector.
Absolutely this. I wasn’t aware that Debs were still using MD5s and am now quite disturbed by this. Time to dig through some source.
In theory (whitepaper is still being written), if you MITM the connection to the APT mirror it’s using you can also carry out the attack over the network by injecting it into the package on the fly. Cert pinning might be a blocker, but local (LAN) package mirrors might still be valid attack targets. Enterprises often use MITM certs for things like DLP and packet inspection we might be able to leverage at least.
Yeah. This is a pretty big issue. Proper handling of MitM certs via a trusted root CA on the enterprise machines could mitigate a bit by avoiding use of TLS skip-verify but, there’s still a wider threat surface than there should be due to the use of MD5. Sub-second collisions means that malicious code could be readily inserted by an adversary through something like that xz backdoor and likely go unnoticed for much longer.
Time to figure out contributing to Debian.
To save you some effort, they do not consider it a priority to fix. Code was attempted to merge that would make package signatures the default, but it was removed because it “was a waste of cpu cycles” when “md5 and the https was just as good”. I’m not kidding, you can find the whole conversation in the Debian mailing archives. So instead I’m going to make it known how dumb it is, and encourage people to use something else.
Cough Fedora does that (using rpm-sequoia written in Rust) and also uses zst instead of xz for RPMs since Fedora 31
Did they ever make good on this plan?