9 ms·

The sad state of Linux download security

79 points by qfx3 10y ago

jacquesm 10y ago
https://noncombatant.org/2014/03/03/downloading-software-safely-is-nearly-impossible/ https://noncombatant.org/2014/03/03/downloading-software-saf... https://news.ycombinator.com/item?id=7334269 https://news.ycombinator.com/item?id=7334269 https://news.ycombinator.com/item?id=11234589 https://news.ycombinator.com/item?id=11234589
fabiofzero 10y ago
The sad state of alarmist posts for karma.
- goodplay 10y ago
  > alarmist How so? The author is voicing criticism that a lot of people (including myself) have with regards to the current state of software distribution security. Furthermore, his survey of the top distributions is interesting for people who take their security seriously.
  - zdkl 10y ago
    It's misconstruing the problem as a primarily mitm threat. Considering the different methods of tampering with your download, I'd be more worried about server side compromises rather than otw
    - goodplay 10y ago
      That doesn't mean we shouldn't mitigate MITM. Using either gpg or tls without the other makes the security of the system weaker than it needs to be. Gpg key authenticity can't be practically verified by end users. I remain unconvinced.
- nickpsecurity 10y ago
  The table in the link isn't alarmist: it's alarming. Secure distribution... at least an effort... was a requirement in INFOSEC since the Orange Book in 90's. FOSS proponents pushed Linux distro's, and still do, for the foundation of security-oriented projects. This is 2016. They still don't have trustworthy distribution under control except Fedora apparently. It's worth noting. Anyone wanting to build on this should apply same methodology to major BSD's to see how they compare.
  - Etzos 10y ago
    I don't think the table really covers the everything quite well enough. In reality it doesn't really matter if the download is over HTTP or HTTPS as long as you can safely verify that the file you have is indeed the correct file. For example, Arch has HTTP downloads but the download page provides the MD5SUM, SHA1SUM, and PGP signature for verification that the files are correct. I just don't really see this as that big of an issue right now. Even if one has provided instructions for doing so it's still going to require that the end user cares about checking the validity of the files.
    - nickpsecurity 10y ago
      "Arch has HTTP downloads but the download page provides the MD5SUM, SHA1SUM, and PGP signature for verification that the files are correct. I just don't really see this as that big of an issue right now." One of the points in that and article jacquesm linked is that checksum verification still requires trusting the transport. Otherwise, you get fake binary plus fake checksum that then look safe but were for malicious app. There's just an extra thing to change for attacker. No work at all given what was already put in to get to that point. So, trustworthy transport of binary and/or checksum is necessary. The checksum should still be there even if binary is sent safely, though, to verify no corruption of binary happened due to transmission or storage faults.
      - Etzos 10y ago
        The checksums and PGP signature are on the HTTPS page which links to all the downloads. You have to trust that page from the start no matter what (or establish the PGP signature trust from other ways, which is quite possible just far more involved) because that's the source of all downloads and anything there could be faked from mirror links to checksums to PGP signature (assuming no trust chain is actually established by the user). My initial point is that no matter the solutions offered, the user has to care about checking. Forcing HTTPS transport for the download isn't really going to make it any more secure because it's still possible the file is illegitimate and you should be testing the signatures. tl;dr: Arch's downloads are over HTTP, the checksums and signature are over HTTPS and on the official download page.
minitech 10y ago
This table says that Arch downloads aren’t over HTTPS, but the preferred way to get them is through a torrent, which is served (both the magnet link and the file) over HTTPS. It also means checksum verification instructions are unnecessary.
- zdkl 10y ago
  Assuming you trust your torrent client to verify file integrity/sums correctly, you'd probably still want to compare the author's checksum to the one on the torrent providers side at least
  - minitech 10y ago
    What do you mean “on the torrent provider’s side”? They’re all on the same server, and the magnet link and hash digests are even part of the same page.
    - zdkl 10y ago
      You're assuming the server is secure
      - minitech 10y ago
        Yes. If you assume the server isn’t secure, there’s no point in any of the other things except the PGP signature, the keys corresponding to which I wouldn’t be able to get anywhere without making some other assumption of security.
      - Etzos 10y ago
        If the source server is compromised then nothing can help you. All source links can be changed to something malicious and all verification methods can be different to match the ones of the bad file. If the source server is compromised there is no way to accurately verify the file's source (unless using verified PGP signatures which you've already vetted).
goodplay 10y ago
Canonical in particular makes it very difficult to download images over HTTPS. For Ubuntu 16.04, I spent a relatively large amount of time trying to figure out the best way to download this image over HTTPS: After going through multiple mirrors, I eventually found a reputable mirror that offered secure downloads. Seeing that there is no way for me to verify the authenticity of the signing keys (short of visiting canonical in person), every bit of security helps.
- nickpsecurity 10y ago
  It's worse: they don't have the updater working properly either. I switched to Ubuntu after the security issues with Mint since I didn't want to re-learn all the grunt stuff associated with Fedora or whatever. Not yet anyway. A while in, I find it won't update the software because /boot or something is out of space. I figure whatever causes that should be automatically prevented by Ubuntu given it is in many other OS's. Gonna have to once again Google around to fix the problem or start from scratch with new install or distro. Might just bite the bullet to learn Fedora given it consistently ranks higher in security metrics. Don't know about quality or UX experience, though. So, distributions and updates have issues in Ubuntu. The very things you want to be painless & secure.
  - nol13 10y ago
    While this issue is easy to fix, I've run into it too and it's annoying and shouldn't happen in the default config/install of a popular OS.
  - danjoc 10y ago
    >A while in, I find it won't update the software because /boot or something is out of space The boot partition is small and Ubuntu doesn't clean out old kernels. You have to do it yourself. sudo apt-get autoremove This will remove an old kernel. There may be a better way, because I find if there are multiple old kernels I have to do this multiple times. I also found if I have to remove more than one, it's best to follow with a sudo update-grub I previously managed to hose things by removing multiple old kernel versions, seeing a warning about needing to do this, ignoring it, then rebooting. So now I just do it after any autoremove that tosses an old kernel. This may not be the 100% correct magic ubuntu dance, but it is the one that seems to work for me.
xorcist 10y ago
What could https possibly defend against here? Packages and other software needs to be secure at rest, not in transit. That much was learnt in the 90s. Nobody is going to target you with a mitm attack to inject a false image. Mirrors are the weakest link. There are mentions of signatures but that these are "too hard". I looked at the Debian cdimage download and I end up in a directory with iso images and gpg signatures, so they're hardly invisible. There should be better instructions how to actually verify them, but inconstructive rants accomplish nothing.
- JonathonW 10y ago
  Yep, nobody's going to target you with an MITM attack to inject a false image: http://www.symantec.com/connect/blogs/w32flamer-microsoft-windows-update-man-middle http://www.symantec.com/connect/blogs/w32flamer-microsoft-wi...
  - xorcist 10y ago
    A good example. Malware that uses wpad acts on unencrypted traffic. Transport security such as https does not protect against this type of attacks.
- nitrogen 10y ago
  Transit encryption provides privacy as well as a minimal level of authentication.
  - clarry 10y ago
    But the watchmen can still see you connect to the IP address of yourfavoritelinux.org or its mirror. And then they can see you transfer approximately a distro image sized chunk of data. Perhaps you just downloaded your favorite linux distro? I argue that the privacy provided is minimal, and for real privacy, you'll have to find something like tor (not an endorsement of it) or alternative, anonymous channels... As for authentication, yes, it is quite minimal. So HTTPS doesn't solve any problem well (meanwhile introducing some of its own problems). The better solutions to these problems make HTTPS wholly unnecessary. I find the fixation on HTTPS bizarre, even concerning. Would the author have written this piece if all distros ticked all the three HTTPS boxes? Would he then no longer consider the state of things sad? That would be dangerous. That would be alarming. I hate the "false sense of security" argument that people apply to just about anything these days.. but this would be it.
gmluke 10y ago
Worth noting that a GPG signature is of limited (though not zero) use if the signing key doesn't have any signatures. In this respect, Debian contrasted favourably with Fedora the last time I looked.
- slrz 10y ago
  True, but for both of them you already might be able to get the proper key through a trusted channel. Fedora has the keyrings for at least Arch, Debian and Ubuntu (besides its own ones, naturally) in its RPM repos, so Fedora users can get them in a secure manner. Debian also has at least the Ubuntu keys included in the repos. Fedora's own key is also available over HTTPS so you get at least some assurance when bootstrapping.
- detaro 10y ago
  Being the same for a long time also helps. E.g. if you search google for the openSUSE key you find a lot of older pages citing the fingerprint.
falcolas 10y ago
IMHO, if a signature is offered, and you have the capability of verifying it, this trumps HTTP, HTTPS, HSTS, checksums, etc. HTTPS can be MITMed by anybody with a root certificate (or who is able to dupe the holder of a root certificate). Signatures rely on (at best) multiple hosts or domains not being compromised. You can also mirror and cache distro ISOs when retrieved by HTTP or bittorrent. In the end, who cares how you downloaded it, so long as you can verify it with a GPG signature?
- sdegutis 10y ago
  ... as long as you know the signature offered is correct and wasn't also hijacked.
  - falcolas 10y ago
    So long as the secret key was not compromised, then the signature file also just doesn't matter - if it's compromised, the validation fails. One of the beauties of asymmetric encryption, making GPG worth learning about.
    - Flimm 10y ago
      You also have to know that the public key you have is the one that corresponds to the secret key that they have.
    - x1798DE 10y ago
      I think this really only applies for signatures you can trust. A frightening number of keys used to sign software are not signed by anyone, so they're effectively the equivalent of a self signed certificate. I've also found some projects where the key used to sign the software isn't even consistent between releases, so you don't even have the (minimal) protection offered by checking the signatures against "known good" builds.
      - gmluke 10y ago
        I'd be happy to be corrected, but I think this applied to the Fedora keys?
vbernat 10y ago
For Debian, the author says: "Official releases of Debian CDs come with signed checksum files; look for them alongside the images in the iso-cd, jigdo-dvd, iso-hybrid etc. directories." No directory or direct links are provided. Verification instructions are not linked to from the download page. I do: - https://www.debian.org/ https://www.debian.org/ - https://www.debian.org/CD/ https://www.debian.org/CD/ - https://www.debian.org/CD/http-ftp/ https://www.debian.org/CD/http-ftp/ - https://www.debian.org/CD/http-ftp/#stable https://www.debian.org/CD/http-ftp/#stable - http://cdimage.debian.org/debian-cd/8.5.0/amd64/iso-cd/ http://cdimage.debian.org/debian-cd/8.5.0/amd64/iso-cd/ And here, along the images, there are difficult to miss (and GPG-signed) SHA256SUMS and SHA512SUMS files. Moreover, the last page clearly links the verification instructions in the "How can I verify my download is correct and exactly what has been created by Debian?" section.
- qfx3 10y ago
  Hmm... I do: - https://www.debian.org/ https://www.debian.org/ - Click "Getting Debian"... - https://www.debian.org/distrib/ https://www.debian.org/distrib/ (no signatures, no checksums, no "verify" link) - Click "Download an installation image"... - https://www.debian.org/distrib/netinst https://www.debian.org/distrib/netinst (no signatures, no checksums, no "verify" link) - Click on my architecture, the ISO download starts - The file is now on my machine and I have not seen the words "signature", "GPG", "checksum", or "verify" anywhere. I eventually found https://www.debian.org/CD/verify https://www.debian.org/CD/verify using a Google search. It's safe to say there is room for improvement here.
G3E9 10y ago
I've gotten passed this with the help of two reasons, the first is because ISO images (even for minimal installs...) are huge and HTTPS'ing it all would be an expense from the mirror's end (hopefully with better tech this'll become an after-thought...) and secondly I've learned enough to generate my own checksums to copy and paste across search engines (in Google and with quotes, search strictly for your checksum and look for multiple sources sharing the same context regarding your download/image.) I've had the luck finding and verifying the majority of what I'd concern myself with. But what really frustrates me is downloading something (verified and all...) and then record its traffic downloading its updates via HTTP. I don't know if it's verifying its own downloads but I simply wish applications were more transparent or that applications had no shame in throwing up a screen providing the checksums of its downloads (well maybe for the users like me who have the time to put towards verifying every thing coming in.) So I love Notepad++, but I hate how its plugin manager (last time I checked...) downloads the majority of, if not all, its plugins from sourceforge and over HTTP. Windows UAC will pop up saying the newly selected plugins want to make changes to my computer - no, I stop there. If I can, then I'll download the plugin from its developer's GitHub and prepare it to use for Notepad++ myself. The plugin manager could be verifying packages, the packages could be hosted on something other than sourceforge, or whatever else. This is a rant over things I've already built habits and routines around.
- slrz 10y ago
  At least for Linux distribution (basically all of them), update installation is through signed packages that get verified using known keys.
Aeolos 10y ago
Does bittorrent provide a measure of security against such attempts? Provided you can trust the magnet link or torrent file?
- ungzd 10y ago
  It uses sha-1 for each piece of content. Although sha-1 considered insecure, I'm not sure of practical possibility to introduce collisions while injecting working malware. Should be very hard.
blfr 10y ago
I'm surprised more distros don't just offer you a .torrent file over https. After you get that from a trusted source, you can download the files/ISO/image from wherever (webseeds, random people on the Internet) and the torrent client will do all the checksumming for you automatically on the fly. It's also easy, simple and cheap to maintain while already being popular enough among your target audience. Certainly more people know how to run a torrent download than how to check GPG/PGP signatures or even would run a regular checksum.
tedunangst 10y ago
The sad state of mobile browsing: fixed unscrollable view ports diminish the utility of tables of data.
kardos 10y ago
A followup on package update delivery would be quite interesting. While the updates are (probably) universally signed to prevent tampering, delivering them in the clear is still an infoleak -- attackers can monitor the update traffic to identify packages that a target has installed, including the exact version, revealing which packages are fully patched and which are still vulnerable.
- viraptor 10y ago
  It's not a big information leak though. Once you know what the system is (which is usually trivial), how many versions do you usually have to choose from? 2-3? At that point you can just try to exploit for each version. Why do you think knowing the version beforehand helps?
  - kardos 10y ago
    I agree it's only a modest infoleak. Depending on the nature of the exploit you may not have multiple attempts. Consider also that one can block updates by serving the client stale update lists/packages. The client sees "no updates available" and thus the attacker can extend a window of vulnerability. Using TLS on the update delivery mirrors raises the bar.
_RPM 10y ago
Why doesn't Ubuntu let you download via HTTPS?
slrz 10y ago
Incredibly, there does not appear to be any way whatsoever to securely verify downloads from respected openSUSE. That seems not only incredible, but plain false. OpenSUSE offers PGP-signed checksum files prominently with the images. It also provides the signing key's fingerprint over HTTPS. When choosing the regular releases you also get some verification instructions. This is not true when picking the Tumbleweed rolling-release distribution. In either case, though, the checksum files are signed.
oliwarner 10y ago
More like: The sad state of security "journalism". Author doesn't have a clue what they're writing about. Packages are signed with strong hashes. Their signatures verified in lists that are themselves signed by trusted keys. Images have HTTPS-verifiable, even out-of-band if you have any friends. To say that this is in any way insecure because package transit isn't done over an encrypted link is lunacy. A minor, potential privacy issue maybe but if you're that bothered, mirror the whole repo.
- jgome 10y ago
  He's talking about ISO images, though.
  - oliwarner 10y ago
    Me too (in part, though I missed the word "hash"). Natural collisions exist but it's bloody hard work to force a collision on a modified 800MB binary file. That's well before you consider the group security of torrents (hashed chunks, optional SSL on tracker, etc). It's easier to distract somebody and get physical access to their computer.
    - AgentME 10y ago
      I'm not really following you at all. I just went to download the Ubuntu ISO. Everything was over HTTP, and I was not instructed to use or even offered any gpg signatures. I didn't see anything about hashes (which would need to be signed or offered over HTTPS to mean anything).
      - oliwarner 10y ago
        The page you went through [1], contains this: > Verify your download - If you want to verify the data integrity and authenticity of your Ubuntu download, follow our guide. Learn how to verify [2] › Yes, this could be more prominent. Yes, this download could be offered over SSL. Yes, ubuntu.com should definitely force-on SSL (rather than force-off). But these don't equate to a process that is impossible to securely verify. You can. The SHA and MD5 checksums are both GPG-signed [3]. [1]: http://www.ubuntu.com/download/desktop/thank-you?country=GB&version=16.04&architecture=amd64 http://www.ubuntu.com/download/desktop/thank-you?country=GB&... [2]: http://www.ubuntu.com/download/how-to-verify http://www.ubuntu.com/download/how-to-verify [3]: http://releases.ubuntu.com/16.04/ http://releases.ubuntu.com/16.04/
deleted 10y ago
[deleted]
rbrownsuse 10y ago
Incredibly, there does not appear to be any way whatsoever to securely verify downloads from respected openSUSE. Seriously? the author has no idea what they're talking about http://software.opensuse.org http://software.opensuse.org "For each ISO, we offer a checksum file with the corresponding SHA256 sum. For extra security, you can use GPG to verify who signed those .sha256 files. It should be 22C0 7BA5 3417 8CD0 2EFE 22AA B88B 2FD4 3DBD C284." https://en.opensuse.org/openSUSE:Tumbleweed_installation https://en.opensuse.org/openSUSE:Tumbleweed_installation http://download.opensuse.org/tumbleweed/iso/openSUSE-Tumbleweed-DVD-x86_64-Current.iso.sha256 http://download.opensuse.org/tumbleweed/iso/openSUSE-Tumblew... http://download.opensuse.org/tumbleweed/iso/openSUSE-Tumbleweed-DVD-i586-Current.iso.sha256 http://download.opensuse.org/tumbleweed/iso/openSUSE-Tumblew... http://download.opensuse.org/distribution/leap/42.1/iso/openSUSE-Leap-42.1-DVD-x86_64.iso.sha256 http://download.opensuse.org/distribution/leap/42.1/iso/open... http://download.opensuse.org/distribution/leap/42.1/iso/openSUSE-Leap-42.1-NET-x86_64.iso.sha256 http://download.opensuse.org/distribution/leap/42.1/iso/open... All signed, happy and healthy...and regularly checked.. people really should double check before making statements like this..
- tyho 10y ago
  All signed, with the signature keys delivered over HTTP, just as the site states.
  - rbrownsuse 10y ago
    the site states that openSUSE does not sign it's checksums or provide instructions on how to verify them Both claims are demonstrably false.
  - detaro 10y ago
    https://software.opensuse.org/ https://software.opensuse.org/ offers the GPG fingerprint over HTTPS. A bit curious that they don't enforce HTTPS for this page, but it is there. And the key has been the same for years, so there are quite a few independent sources quoting it, which helps to verify it.
walrus01 10y ago
Since when are checksums for Debian ISOs "hard to find" ?
- vacri 10y ago
  If you know Debian, they're not, but if you go through the website like a new user, they are.
mangix 10y ago
the author thinks MD5 is insecure as a checksum. ROFL.
- trav4225 10y ago
  It's not insecure as a checksum against inadvertent diffs. It is insecure as a checksum against intentional diffs.
0xcde4c3db 10y ago
I usually just hash the ISO and plug the hash into Google to see who else agrees with it. I figure that if someone has the ability to fuck with both my (HTTPS) Google results and my ISO downloads, I'm probably already too compromised for any third-party security infrastructure to help.
btrask 10y ago
My own project, https://hash-archive.org https://hash-archive.org, is intended to help with this to some degree. The idea is to provide a 3rd party source for cryptographic hashes of files on the web. Recent Show HN: https://news.ycombinator.com/item?id=11843214 https://news.ycombinator.com/item?id=11843214

79 points by qfx3 10y ago

https://noncombatant.org/2014/03/03/downloading-software-safely-is-nearly-impossible/ https://noncombatant.org/2014/03/03/downloading-software-saf... https://news.ycombinator.com/item?id=7334269 https://news.ycombinator.com/item?id=7334269 https://news.ycombinator.com/item?id=11234589 https://news.ycombinator.com/item?id=11234589

fabiofzero 10y ago

The sad state of alarmist posts for karma.

goodplay 10y ago
> alarmist How so? The author is voicing criticism that a lot of people (including myself) have with regards to the current state of software distribution security. Furthermore, his survey of the top distributions is interesting for people who take their security seriously.
- zdkl 10y ago
  It's misconstruing the problem as a primarily mitm threat. Considering the different methods of tampering with your download, I'd be more worried about server side compromises rather than otw
  - goodplay 10y ago
    That doesn't mean we shouldn't mitigate MITM. Using either gpg or tls without the other makes the security of the system weaker than it needs to be. Gpg key authenticity can't be practically verified by end users. I remain unconvinced.
nickpsecurity 10y ago
The table in the link isn't alarmist: it's alarming. Secure distribution... at least an effort... was a requirement in INFOSEC since the Orange Book in 90's. FOSS proponents pushed Linux distro's, and still do, for the foundation of security-oriented projects. This is 2016. They still don't have trustworthy distribution under control except Fedora apparently. It's worth noting. Anyone wanting to build on this should apply same methodology to major BSD's to see how they compare.
- Etzos 10y ago
  I don't think the table really covers the everything quite well enough. In reality it doesn't really matter if the download is over HTTP or HTTPS as long as you can safely verify that the file you have is indeed the correct file. For example, Arch has HTTP downloads but the download page provides the MD5SUM, SHA1SUM, and PGP signature for verification that the files are correct. I just don't really see this as that big of an issue right now. Even if one has provided instructions for doing so it's still going to require that the end user cares about checking the validity of the files.
  - nickpsecurity 10y ago
    "Arch has HTTP downloads but the download page provides the MD5SUM, SHA1SUM, and PGP signature for verification that the files are correct. I just don't really see this as that big of an issue right now." One of the points in that and article jacquesm linked is that checksum verification still requires trusting the transport. Otherwise, you get fake binary plus fake checksum that then look safe but were for malicious app. There's just an extra thing to change for attacker. No work at all given what was already put in to get to that point. So, trustworthy transport of binary and/or checksum is necessary. The checksum should still be there even if binary is sent safely, though, to verify no corruption of binary happened due to transmission or storage faults.
    - Etzos 10y ago
      The checksums and PGP signature are on the HTTPS page which links to all the downloads. You have to trust that page from the start no matter what (or establish the PGP signature trust from other ways, which is quite possible just far more involved) because that's the source of all downloads and anything there could be faked from mirror links to checksums to PGP signature (assuming no trust chain is actually established by the user). My initial point is that no matter the solutions offered, the user has to care about checking. Forcing HTTPS transport for the download isn't really going to make it any more secure because it's still possible the file is illegitimate and you should be testing the signatures. tl;dr: Arch's downloads are over HTTP, the checksums and signature are over HTTPS and on the official download page.

minitech 10y ago

This table says that Arch downloads aren’t over HTTPS, but the preferred way to get them is through a torrent, which is served (both the magnet link and the file) over HTTPS. It also means checksum verification instructions are unnecessary.

zdkl 10y ago
Assuming you trust your torrent client to verify file integrity/sums correctly, you'd probably still want to compare the author's checksum to the one on the torrent providers side at least
- minitech 10y ago
  What do you mean “on the torrent provider’s side”? They’re all on the same server, and the magnet link and hash digests are even part of the same page.
  - zdkl 10y ago
    You're assuming the server is secure
    - minitech 10y ago
      Yes. If you assume the server isn’t secure, there’s no point in any of the other things except the PGP signature, the keys corresponding to which I wouldn’t be able to get anywhere without making some other assumption of security.
    - Etzos 10y ago
      If the source server is compromised then nothing can help you. All source links can be changed to something malicious and all verification methods can be different to match the ones of the bad file. If the source server is compromised there is no way to accurately verify the file's source (unless using verified PGP signatures which you've already vetted).

goodplay 10y ago

Canonical in particular makes it very difficult to download images over HTTPS. For Ubuntu 16.04, I spent a relatively large amount of time trying to figure out the best way to download this image over HTTPS: After going through multiple mirrors, I eventually found a reputable mirror that offered secure downloads. Seeing that there is no way for me to verify the authenticity of the signing keys (short of visiting canonical in person), every bit of security helps.

nickpsecurity 10y ago
It's worse: they don't have the updater working properly either. I switched to Ubuntu after the security issues with Mint since I didn't want to re-learn all the grunt stuff associated with Fedora or whatever. Not yet anyway. A while in, I find it won't update the software because /boot or something is out of space. I figure whatever causes that should be automatically prevented by Ubuntu given it is in many other OS's. Gonna have to once again Google around to fix the problem or start from scratch with new install or distro. Might just bite the bullet to learn Fedora given it consistently ranks higher in security metrics. Don't know about quality or UX experience, though. So, distributions and updates have issues in Ubuntu. The very things you want to be painless & secure.
- nol13 10y ago
  While this issue is easy to fix, I've run into it too and it's annoying and shouldn't happen in the default config/install of a popular OS.
- danjoc 10y ago
  >A while in, I find it won't update the software because /boot or something is out of space The boot partition is small and Ubuntu doesn't clean out old kernels. You have to do it yourself. sudo apt-get autoremove This will remove an old kernel. There may be a better way, because I find if there are multiple old kernels I have to do this multiple times. I also found if I have to remove more than one, it's best to follow with a sudo update-grub I previously managed to hose things by removing multiple old kernel versions, seeing a warning about needing to do this, ignoring it, then rebooting. So now I just do it after any autoremove that tosses an old kernel. This may not be the 100% correct magic ubuntu dance, but it is the one that seems to work for me.

xorcist 10y ago

What could https possibly defend against here? Packages and other software needs to be secure at rest, not in transit. That much was learnt in the 90s. Nobody is going to target you with a mitm attack to inject a false image. Mirrors are the weakest link. There are mentions of signatures but that these are "too hard". I looked at the Debian cdimage download and I end up in a directory with iso images and gpg signatures, so they're hardly invisible. There should be better instructions how to actually verify them, but inconstructive rants accomplish nothing.

JonathonW 10y ago
Yep, nobody's going to target you with an MITM attack to inject a false image: http://www.symantec.com/connect/blogs/w32flamer-microsoft-windows-update-man-middle http://www.symantec.com/connect/blogs/w32flamer-microsoft-wi...
- xorcist 10y ago
  A good example. Malware that uses wpad acts on unencrypted traffic. Transport security such as https does not protect against this type of attacks.
nitrogen 10y ago
Transit encryption provides privacy as well as a minimal level of authentication.
- clarry 10y ago
  But the watchmen can still see you connect to the IP address of yourfavoritelinux.org or its mirror. And then they can see you transfer approximately a distro image sized chunk of data. Perhaps you just downloaded your favorite linux distro? I argue that the privacy provided is minimal, and for real privacy, you'll have to find something like tor (not an endorsement of it) or alternative, anonymous channels... As for authentication, yes, it is quite minimal. So HTTPS doesn't solve any problem well (meanwhile introducing some of its own problems). The better solutions to these problems make HTTPS wholly unnecessary. I find the fixation on HTTPS bizarre, even concerning. Would the author have written this piece if all distros ticked all the three HTTPS boxes? Would he then no longer consider the state of things sad? That would be dangerous. That would be alarming. I hate the "false sense of security" argument that people apply to just about anything these days.. but this would be it.

gmluke 10y ago

Worth noting that a GPG signature is of limited (though not zero) use if the signing key doesn't have any signatures. In this respect, Debian contrasted favourably with Fedora the last time I looked.

slrz 10y ago
True, but for both of them you already might be able to get the proper key through a trusted channel. Fedora has the keyrings for at least Arch, Debian and Ubuntu (besides its own ones, naturally) in its RPM repos, so Fedora users can get them in a secure manner. Debian also has at least the Ubuntu keys included in the repos. Fedora's own key is also available over HTTPS so you get at least some assurance when bootstrapping.
detaro 10y ago
Being the same for a long time also helps. E.g. if you search google for the openSUSE key you find a lot of older pages citing the fingerprint.

falcolas 10y ago

IMHO, if a signature is offered, and you have the capability of verifying it, this trumps HTTP, HTTPS, HSTS, checksums, etc. HTTPS can be MITMed by anybody with a root certificate (or who is able to dupe the holder of a root certificate). Signatures rely on (at best) multiple hosts or domains not being compromised. You can also mirror and cache distro ISOs when retrieved by HTTP or bittorrent. In the end, who cares how you downloaded it, so long as you can verify it with a GPG signature?

sdegutis 10y ago
... as long as you know the signature offered is correct and wasn't also hijacked.
- falcolas 10y ago
  So long as the secret key was not compromised, then the signature file also just doesn't matter - if it's compromised, the validation fails. One of the beauties of asymmetric encryption, making GPG worth learning about.
  - Flimm 10y ago
    You also have to know that the public key you have is the one that corresponds to the secret key that they have.
  - x1798DE 10y ago
    I think this really only applies for signatures you can trust. A frightening number of keys used to sign software are not signed by anyone, so they're effectively the equivalent of a self signed certificate. I've also found some projects where the key used to sign the software isn't even consistent between releases, so you don't even have the (minimal) protection offered by checking the signatures against "known good" builds.
    - gmluke 10y ago
      I'd be happy to be corrected, but I think this applied to the Fedora keys?

vbernat 10y ago

For Debian, the author says: "Official releases of Debian CDs come with signed checksum files; look for them alongside the images in the iso-cd, jigdo-dvd, iso-hybrid etc. directories." No directory or direct links are provided. Verification instructions are not linked to from the download page. I do: - https://www.debian.org/ https://www.debian.org/ - https://www.debian.org/CD/ https://www.debian.org/CD/ - https://www.debian.org/CD/http-ftp/ https://www.debian.org/CD/http-ftp/ - https://www.debian.org/CD/http-ftp/#stable https://www.debian.org/CD/http-ftp/#stable - http://cdimage.debian.org/debian-cd/8.5.0/amd64/iso-cd/ http://cdimage.debian.org/debian-cd/8.5.0/amd64/iso-cd/ And here, along the images, there are difficult to miss (and GPG-signed) SHA256SUMS and SHA512SUMS files. Moreover, the last page clearly links the verification instructions in the "How can I verify my download is correct and exactly what has been created by Debian?" section.

qfx3 10y ago
Hmm... I do: - https://www.debian.org/ https://www.debian.org/ - Click "Getting Debian"... - https://www.debian.org/distrib/ https://www.debian.org/distrib/ (no signatures, no checksums, no "verify" link) - Click "Download an installation image"... - https://www.debian.org/distrib/netinst https://www.debian.org/distrib/netinst (no signatures, no checksums, no "verify" link) - Click on my architecture, the ISO download starts - The file is now on my machine and I have not seen the words "signature", "GPG", "checksum", or "verify" anywhere. I eventually found https://www.debian.org/CD/verify https://www.debian.org/CD/verify using a Google search. It's safe to say there is room for improvement here.

G3E9 10y ago

I've gotten passed this with the help of two reasons, the first is because ISO images (even for minimal installs...) are huge and HTTPS'ing it all would be an expense from the mirror's end (hopefully with better tech this'll become an after-thought...) and secondly I've learned enough to generate my own checksums to copy and paste across search engines (in Google and with quotes, search strictly for your checksum and look for multiple sources sharing the same context regarding your download/image.) I've had the luck finding and verifying the majority of what I'd concern myself with. But what really frustrates me is downloading something (verified and all...) and then record its traffic downloading its updates via HTTP. I don't know if it's verifying its own downloads but I simply wish applications were more transparent or that applications had no shame in throwing up a screen providing the checksums of its downloads (well maybe for the users like me who have the time to put towards verifying every thing coming in.) So I love Notepad++, but I hate how its plugin manager (last time I checked...) downloads the majority of, if not all, its plugins from sourceforge and over HTTP. Windows UAC will pop up saying the newly selected plugins want to make changes to my computer - no, I stop there. If I can, then I'll download the plugin from its developer's GitHub and prepare it to use for Notepad++ myself. The plugin manager could be verifying packages, the packages could be hosted on something other than sourceforge, or whatever else. This is a rant over things I've already built habits and routines around.

slrz 10y ago
At least for Linux distribution (basically all of them), update installation is through signed packages that get verified using known keys.

Aeolos 10y ago

Does bittorrent provide a measure of security against such attempts? Provided you can trust the magnet link or torrent file?

ungzd 10y ago
It uses sha-1 for each piece of content. Although sha-1 considered insecure, I'm not sure of practical possibility to introduce collisions while injecting working malware. Should be very hard.

blfr 10y ago

I'm surprised more distros don't just offer you a .torrent file over https. After you get that from a trusted source, you can download the files/ISO/image from wherever (webseeds, random people on the Internet) and the torrent client will do all the checksumming for you automatically on the fly. It's also easy, simple and cheap to maintain while already being popular enough among your target audience. Certainly more people know how to run a torrent download than how to check GPG/PGP signatures or even would run a regular checksum.

tedunangst 10y ago

The sad state of mobile browsing: fixed unscrollable view ports diminish the utility of tables of data.

kardos 10y ago

A followup on package update delivery would be quite interesting. While the updates are (probably) universally signed to prevent tampering, delivering them in the clear is still an infoleak -- attackers can monitor the update traffic to identify packages that a target has installed, including the exact version, revealing which packages are fully patched and which are still vulnerable.

viraptor 10y ago
It's not a big information leak though. Once you know what the system is (which is usually trivial), how many versions do you usually have to choose from? 2-3? At that point you can just try to exploit for each version. Why do you think knowing the version beforehand helps?
- kardos 10y ago
  I agree it's only a modest infoleak. Depending on the nature of the exploit you may not have multiple attempts. Consider also that one can block updates by serving the client stale update lists/packages. The client sees "no updates available" and thus the attacker can extend a window of vulnerability. Using TLS on the update delivery mirrors raises the bar.

_RPM 10y ago

Why doesn't Ubuntu let you download via HTTPS?

slrz 10y ago

Incredibly, there does not appear to be any way whatsoever to securely verify downloads from respected openSUSE. That seems not only incredible, but plain false. OpenSUSE offers PGP-signed checksum files prominently with the images. It also provides the signing key's fingerprint over HTTPS. When choosing the regular releases you also get some verification instructions. This is not true when picking the Tumbleweed rolling-release distribution. In either case, though, the checksum files are signed.

oliwarner 10y ago

More like: The sad state of security "journalism". Author doesn't have a clue what they're writing about. Packages are signed with strong hashes. Their signatures verified in lists that are themselves signed by trusted keys. Images have HTTPS-verifiable, even out-of-band if you have any friends. To say that this is in any way insecure because package transit isn't done over an encrypted link is lunacy. A minor, potential privacy issue maybe but if you're that bothered, mirror the whole repo.

jgome 10y ago
He's talking about ISO images, though.
- oliwarner 10y ago
  Me too (in part, though I missed the word "hash"). Natural collisions exist but it's bloody hard work to force a collision on a modified 800MB binary file. That's well before you consider the group security of torrents (hashed chunks, optional SSL on tracker, etc). It's easier to distract somebody and get physical access to their computer.
  - AgentME 10y ago
    I'm not really following you at all. I just went to download the Ubuntu ISO. Everything was over HTTP, and I was not instructed to use or even offered any gpg signatures. I didn't see anything about hashes (which would need to be signed or offered over HTTPS to mean anything).
    - oliwarner 10y ago
      The page you went through [1], contains this: > Verify your download - If you want to verify the data integrity and authenticity of your Ubuntu download, follow our guide. Learn how to verify [2] › Yes, this could be more prominent. Yes, this download could be offered over SSL. Yes, ubuntu.com should definitely force-on SSL (rather than force-off). But these don't equate to a process that is impossible to securely verify. You can. The SHA and MD5 checksums are both GPG-signed [3]. [1]: http://www.ubuntu.com/download/desktop/thank-you?country=GB&version=16.04&architecture=amd64 http://www.ubuntu.com/download/desktop/thank-you?country=GB&... [2]: http://www.ubuntu.com/download/how-to-verify http://www.ubuntu.com/download/how-to-verify [3]: http://releases.ubuntu.com/16.04/ http://releases.ubuntu.com/16.04/

deleted 10y ago

[deleted]

rbrownsuse 10y ago

Incredibly, there does not appear to be any way whatsoever to securely verify downloads from respected openSUSE. Seriously? the author has no idea what they're talking about http://software.opensuse.org http://software.opensuse.org "For each ISO, we offer a checksum file with the corresponding SHA256 sum. For extra security, you can use GPG to verify who signed those .sha256 files. It should be 22C0 7BA5 3417 8CD0 2EFE 22AA B88B 2FD4 3DBD C284." https://en.opensuse.org/openSUSE:Tumbleweed_installation https://en.opensuse.org/openSUSE:Tumbleweed_installation http://download.opensuse.org/tumbleweed/iso/openSUSE-Tumbleweed-DVD-x86_64-Current.iso.sha256 http://download.opensuse.org/tumbleweed/iso/openSUSE-Tumblew... http://download.opensuse.org/tumbleweed/iso/openSUSE-Tumbleweed-DVD-i586-Current.iso.sha256 http://download.opensuse.org/tumbleweed/iso/openSUSE-Tumblew... http://download.opensuse.org/distribution/leap/42.1/iso/openSUSE-Leap-42.1-DVD-x86_64.iso.sha256 http://download.opensuse.org/distribution/leap/42.1/iso/open... http://download.opensuse.org/distribution/leap/42.1/iso/openSUSE-Leap-42.1-NET-x86_64.iso.sha256 http://download.opensuse.org/distribution/leap/42.1/iso/open... All signed, happy and healthy...and regularly checked.. people really should double check before making statements like this..

tyho 10y ago
All signed, with the signature keys delivered over HTTP, just as the site states.
- rbrownsuse 10y ago
  the site states that openSUSE does not sign it's checksums or provide instructions on how to verify them Both claims are demonstrably false.
- detaro 10y ago
  https://software.opensuse.org/ https://software.opensuse.org/ offers the GPG fingerprint over HTTPS. A bit curious that they don't enforce HTTPS for this page, but it is there. And the key has been the same for years, so there are quite a few independent sources quoting it, which helps to verify it.

walrus01 10y ago

Since when are checksums for Debian ISOs "hard to find" ?

vacri 10y ago
If you know Debian, they're not, but if you go through the website like a new user, they are.

mangix 10y ago

the author thinks MD5 is insecure as a checksum. ROFL.

trav4225 10y ago
It's not insecure as a checksum against inadvertent diffs. It is insecure as a checksum against intentional diffs.

0xcde4c3db 10y ago

I usually just hash the ISO and plug the hash into Google to see who else agrees with it. I figure that if someone has the ability to fuck with both my (HTTPS) Google results and my ISO downloads, I'm probably already too compromised for any third-party security infrastructure to help.

btrask 10y ago

My own project, https://hash-archive.org https://hash-archive.org, is intended to help with this to some degree. The idea is to provide a 3rd party source for cryptographic hashes of files on the web. Recent Show HN: https://news.ycombinator.com/item?id=11843214 https://news.ycombinator.com/item?id=11843214