
The sad state of Linux download security - qfx3
http://worldwidemann.com/the-sad-state-of-linux-download-security/
======
vbernat
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
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.

------
falcolas
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
... as long as you know the signature offered is correct and wasn't also
hijacked.

~~~
falcolas
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.

~~~
x1798DE
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.

~~~
RaleyField
> 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 wonder how hard would it be to socially engineer yourself into trust chain.
I haven't read GPG manuals, but I'd be surprised if there were strict
protocols followed by everyone when signing others' keys. Most people probably
don't or can't insure that there is no mitm when signing keys and can't
reliably verify that government id papers aren't forgeries so likely reliable
chains of trusts exists only between people that spend large quantities of
time together and exchange fingerprints over secure channel.

------
xorcist
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
Yep, _nobody 's_ going to target you with an MITM attack to inject a false
image: [http://www.symantec.com/connect/blogs/w32flamer-microsoft-
wi...](http://www.symantec.com/connect/blogs/w32flamer-microsoft-windows-
update-man-middle)

~~~
xorcist
A good example. Malware that uses wpad acts on unencrypted traffic.

Transport security such as https does not protect against this type of
attacks.

------
minitech
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
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
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
You're assuming the server is secure

~~~
Etzos
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).

~~~
zdkl
That's my point. Why go to the trouble of securing the transport layer if
you're both NOT using PGP AND assuming with no proof that the server isn't
compromised? I mean sure "security all the things" pays my ramen but at some
point youve gotta wonder if you wouldn't be better off securing a trusted
signature transmission method and comparing your insecure downloads to those
provably correct signatures. I'm not complaining, in the end clients assuming
the server is uncompromised "because otherwise we'd be boned" and relying on
transport security on top of that has secured me most of my work this past
year... :)

~~~
minitech
> Why go to the trouble of securing the transport layer if you're both NOT
> using PGP AND assuming with no proof that the server isn't compromised?

To guard against MITMs as well as DNS spoofing to an extent.

------
oliwarner
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
He's talking about ISO images, though.

~~~
oliwarner
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
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
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&...](http://www.ubuntu.com/download/desktop/thank-
you?country=GB&version=16.04&architecture=amd64)

[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/)

~~~
sliken
Heh, kinda amusing to claim you can verify the ISO, then to verify you post 3
URLs that are easy to MiTM because they are not using HTTPS.

For those that care I suggest:
[https://help.ubuntu.com/community/VerifyIsoHowto](https://help.ubuntu.com/community/VerifyIsoHowto)

It's over HTTPs, and mentions both the short finger prints (0xFBB75451 and
0xEFE21092) as well as the full finger prints (C598 6B4F 1257 FFA8 6632 CBA7
4618 1433 FBB7 5451 and 8439 38DF 228D 22F7 B374 2BC0 D94A A3F0 EFE2 1092).

~~~
oliwarner
The hash-GPGs are securely verifiable.

The community wiki page is editable. Obvious issues there.

------
slrz
_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.

------
goodplay
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
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.

~~~
RaleyField
In default install. Every so often I click updater and there are updates for
CVEs. Why didn't you ask me Ubuntu? Why did you let me run software with known
public vulnerabilities longer than is necessary?? I'm also befuddled why it
sometimes prompts for password and sometimes doesn't, and I can't insure that
the prompt is that of updater so I have to drop in shell and use apt. Or that
it will happily let processes with updated binaries run and not ask to restart
them. Ubuntu is a joke, but then half other distros are or I can't evaluate
the leadership satisfactorily to know if it's a joke (e.g. as I suspected,
Mint turned out to be one as they managed to release hijacked isos twice in a
row). </rant>

~~~
nickpsecurity
Great examples. Especially the password thing. I figured it just remembered it
from prior use. Yet, there were times it didnt ask during somethimg critical.
So, who knows...

------
rbrownsuse
_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-
Tumblew...](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/distribution/leap/42.1/iso/open...](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)

All signed, happy and healthy...and regularly checked.. people really should
double check before making statements like this..

~~~
tyho
All signed, with the signature keys delivered over HTTP, just as the site
states.

~~~
detaro
[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.

------
blfr
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.

------
jacquesm
[https://noncombatant.org/2014/03/03/downloading-software-
saf...](https://noncombatant.org/2014/03/03/downloading-software-safely-is-
nearly-impossible/)

[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
The sad state of alarmist posts for karma.

~~~
nickpsecurity
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
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
"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
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.

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

------
G3E9
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
At least for Linux distribution (basically all of them), update installation
is through signed packages that get verified using known keys.

------
btrask
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)

------
gmluke
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
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.

------
kardos
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
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
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.

------
0xcde4c3db
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.

------
_RPM
Why doesn't Ubuntu let you download via HTTPS?

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

~~~
ungzd
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.

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

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

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

~~~
trav4225
It's not insecure as a checksum against inadvertent diffs. It _is_ insecure as
a checksum against intentional diffs.

