lewisgoddard
commented
7 years ago TL;DR - The short version of this is that GPG keys don't protect against hacked sites unless everyone knows there should be one, and checks for it. Since most people don't check them, they just don't help cover that eventuality. We have several other systems that do.
They are a good security improvement, just not protecting against website hacks.
Okay, so I'm going to start with a brief introduction. My name is Lewis Goddard, I work on elementary's website, notably as the lead on download delivery. I also work with eustasy, and contractually work with other distribution teams.
elementary run their system on five (previously six) distributed servers on Digital Ocean that we discussed when we left SourceForge, although they are technically hosted by eustasy for the reason of unlimited bandwidth.
The Linux Mint hack happened close enough to this deployment that it was queried at the time. I don't have access to the chat logs but the general response from within elementary OS to the standard of my security was "damn, dude."
A guide to hacking elementary OS distribution system
and substituting in your own malware-ridden files
So, let's say you want to distribute a dodgy copy of elementary OS. If you break into the website, to the point where you can modify it's contents, you can simply change the link and remove all references to hashing. You could also remove any references to a GPG signing key, but we'll ignore that minor detail for now. First, you must break in to a server.
There are two systems you can compromise to accomplish your task. Either the automatically deployed front-end, or the delivery network. Either way, you'll have to break through a rate-limited, key-only login with dual-factor for root privileges with usernames you don't know, on a server hidden behind CloudFlare.
Mint was hacked by another known remote-execution vulnerability in an outdated WordPress installation, something we don't use, and another known remote-execution vulnerability in their torrent tracker script, that had been out of support for nearly five years at the time. The way to avoid both of these is to:
- Update everything.
- Don't upload files in a publicly-accessible way.
Assuming you get in fine, on the front-end you have to know how to disable the auto-deployment, so your changes aren't eradicated the next time we change something. A remote-run script checks that the hashes are still in the docs, so don't even think about removing them.
On the delivery network, things are a little more complex. There's two important systems in place on the delivery network servers. That same remote-run script that verifies the hashes of both the distribution files, index, and configs, and a transmission instance, which effectively does the same thing while also working as a seedbox. If you delete or modify the files there, I get a notification and transmission simply overwrites with the correct file. If you turn transmission off, the script notifies me. If you move where Nginx points, transmission notifies me.
Basically don't mess with my servers, I will know.
A guide to hacking the entire internet
and doing whatever the hell you want because, hey, you own google now
If, as you say, someone where to both:
- Redirect practically all elementary.io traffic to their location
- Issue a certificate in the name of elementary.io
then you would effectively be able to do whatever you wanted, including just change basically every clock to say it was the 1st of January 1999.
The way to do this is surprisingly simple. As of the 25th of October 2016, the entire internet runs on 632 servers under 13 addresses. That doesn't seem like much, does it?
Basically compromising these servers would allow you to redirect all traffic wherever you wanted, within a few hours. Getting a certificate is easy with systems like Let's Encrypt, and you can then do whatever you want. There are a couple of upcoming standards against this, but nothing we currently deploy. But why would you, when instead you could:
- Change the time on basically every computer, and probably most phones and radio clocks.
- Make millions of PCs randomly wake up.
- DDOS any website with the entire force of the internet at will.
- Send millions of people to malware, or advert-ridden sites.
- Not do any of those things, because you're not a bad person.
naftulikay
cassidyjames
4jNsY6fCVqZv
danirabbit
Currently, if a user wants to verify the integrity of their download, they are directed here:
https://elementary.io/docs/installation
...where the documentation walks them through the process of verifying the sha256 sum of the .iso file they downloaded.
This is a great first step, but the twin linchpins of this whole arrangement are the elementary.io TLS certificate and the admin access to the site.
Anyone who can issue root certificates is currently in a position to serve users malicious copies of elementary OS. Currently, there is no way to detect this.
In addition, if the elementary.io website were compromised, it would also be possible for an attacker to silently serve malicious binaries, even if they cannot issue root TLS certificates.
Offering users the option to check a GPG signature on either a sha256 checksum file or the .iso file itself would solve this problem.
Other projects, such as Debian and Qubes OS, among others, have opted for signing their releases with an offline GPG signing key.
As the Linux Mint developers discovered, you do not want your website to be the single point of failure in your release security:
http://blog.linuxmint.com/?p=2994