Along with the recent Linux Mint hijack, this really illustrates the need for people to verify programs they download. Though I think most people can't be bothered to verify the checksum on a file every time they download it.
On the other hand, the Windows and OS X App Stores are awful. Linux package managers are looking like one of the only straightforward ways to distribute applications securely.
> Along with the recent Linux Mint hijack, this really illustrates the need for people to verify programs they download. Though I think most people can't be bothered to verify the checksum on a file every time they download it.
Barring a situation where a CDN hosting the download is compromised but the main site is not hosted on the CDN, it's extremely unlikely that someone would have the ability to inject malware into the download and not have the ability to make the checksum match. Posting checksums is actually pretty useless, and was something that used to be used to deal with the possibility of malicious mirrors, but doesn't provide any security against mitm attacks (unless the main site is secure but the downloads aren't which is idiotic by 2016 standards anyway), the site getting hacked, etc.
Digital signatures are a little bit better if the key is kept safe, since hacking the site and replacing the binary won't allow a random person to produce a valid signature, although ability to modify the source code would still allow someone to introduce backdoors into the next version, but there's still a huge problem where you need some way to determine what key was supposed to be used to sign the binary in the first place, so just posting a signature on a website is also basically useless.
Digital signatures can work if there's some sort of centralized distribution method, or for safely updating software that's already installed.
In Debian and Ubuntu at least, all published files containing binary executable files (ISOs, .deb packages, etc.) are hashed and the hash signed by a well-known system pre-installed PGP key.
Given trust in the protection of the private key used to sign the hash list file the integrity of the executable content can be proved (assuming useful SHA1 collision creation is prohibitively expensive).
Coincidentally I was writing a Bash script this weekend to auto-install (Ubuntu) releases into LVM volumes and it includes the following code to verify the download:
set -e
# ...
ISO="${NEW_DIST}-desktop-${ARCH}.iso"
for F in SHA1SUMS SHA1SUMS.gpg ${ISO}; do
if [ ! -r $F ]; then
wget http://cdimage.ubuntu.com/${FLAVOUR}/daily-live/current/$F
fi
done
if ! gpg --verify --keyring /etc/apt/trusted.gpg SHA1SUMS.gpg SHA1SUMS; then
echo "Error: failed to verify the hash file list signature; files may have been tampered with"
exit 2
fi
if ! grep ${ISO} SHA1SUMS | sha1sum -c; then
echo "${ISO} is corrupted; please try again"
exit 1
fi
You'd think there would be some sort of global torrent network that simultaneously distributes binaries and signatures.
Doesn't seem like a horrible idea to me: you could just add the developer's key to your client, have your client broadcast interest, receive a _signed_ list of available software with appropriate magnet info... Download servers could serve as initial trackers until enough information has propagated through the network for downloads to be trackerless.
Checksums? Guaranteed. Signatures? Acquired. Checking? Performed automagically.
Granted, this just moves the point of failure to the developer's key. (Key acquisition needn't necessarily take place on the developer's site, a friend in the network could pass you a link containing the dev's key and the application's magnet info.)
> (unless the main site is secure but the downloads aren't
> which is idiotic by 2016 standards anyway), the site
> getting hacked, etc.
It's not idiotic at all. You let anyone who wants to spread the load by providing downloads, but you use checksums - behind https - to ensure they can be trusted.
I thought only apps signed by "identified developers" are run by default on Macs with Gatekeeper now. Shouldn't code-signing have prevented this? Unless they inserted the malware before the signing process.
>I thought only apps signed by "identified developers" are run by default on Macs with Gatekeeper now. Shouldn't code-signing have prevented this?
"By default". Most developers don't bother to register, and lots of people change the default (and after that, they can right click to open the app and bypass the warning).
Anyone can sign up for the Apple Developer Program to become an "identified developer", so there's nothing that stops an attacker from signing their malware.
And according to the analysis [0], this is exactly what they did. They used a different cert to sign their malware.
I have to admit that Windows' UAC is better in that regard, as it shows the signees name. But of course this is only useful if you know the "right" name.
Yeah, I think this is a major issue on OS X. For the average user it is impossible to tell who signed an app, if it is sandboxed, and what permissions it has. Hell, using the codesign command to extract entitlements from all binaries in a package is hard even for advanced users...
(There is third party tool named RB App Checker which does make these tasks a bit easier, though)
“The two KeRanger infected Transmission installers were signed with a legitimate certificate issued by Apple. The developer ID in this certificate is “POLISAN BOYA SANAYI VE TICARET ANONIM SIRKETI (Z7276PX673)”, which was different from the developer ID used to sign previous versions of the Transmission installer. In the code signing information, we found that these installers were generated and signed on the morning of March 4.”
What. That's interesting -- Polisan is a relatively well-known paint company in Turkey. I don't think they have a part in this -- maybe they did not store their private keys well enough?
For the end user? No, it wouldn’t. As thesimon and jakobegger, respectively, said:
“And according to the analysis, this is exactly what they did. They used a different cert to sign their malware.
I have to admit that Windows' UAC is better in that regard, as it shows the signees name. But of course this is only useful if you know the "right" name.”
“Yeah, I think this is a major issue on OS X. For the average user it is impossible to tell who signed an app, if it is sandboxed, and what permissions it has. Hell, using the codesign command to extract entitlements from all binaries in a package is hard even for advanced users...
(There is third party tool named RB App Checker which does make these tasks a bit easier, though)”
There is also the web of trust for PGP, which sort of solves the problem of needing a central store of the key. It does require being inside the web though (bootstrapping). But once you are, you can construct how much you trust a key from someone you haven't met.
>unless the main site is secure but the downloads aren't which is idiotic by 2016 standards anyway
https adds a performance hit. The security of "checksum over https and actual file over http", if the checksum is checked, is the same as "actual file over https", barring preimage attacks.
Granted, the project I saw this reasoning on (https://www.whonix.org/wiki/Download_Security) is one where users are especially likely to do security checks, and they generally aren't satisfied with the security of SSL anyway.
> just to save a negligibly small number of CPU cycles
The link above says they can't afford the additional cost. If it's so negligible, would you sponder the cost of those extra cycles? I'm sure they would host on SSL if someone covered the cost.
Quote from a google engineer in 2010 (it's only gotten cheaper in the last 6 years w/ advances in CPU tech) regarding SSL overhead:
> On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that. [0]
None of affects the point they're making, which is that they can't find SSL mirrors that aren't more expensive. If you find one, let them know and I'm sure they'll be happy to switch over.
It is 2016. SSL is not slow anymore. Only case it could be deemed slow would be on a webpage where the browser has to download a ton of small files likes images. Each image would require a new connection and each connection would require full SSL handshake. Even then the fix is not to not use SSL but to bundle all the images/files into 1.
Keep in mind the topic at hand is downloading a single large file, the TLS handshake is a rounding error of the total time, regardless of where you are in the world.
>Practically it is difficult to provide SSL protected downloads at all. Many important software projects can only be downloaded in the clear, such as Ubuntu, Debian, Tails, Qubes OS, etc. This is because someone has to pay the bill and SSL (encryption) makes it more expensive. At the moment we don't have any mirror supporting SSL. We're looking for SSL supported mirrors to share the load.
Is it not true that mirrors supporting SSL are more expensive?
No, it's not true anymore. From the link you replied to:
"On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10 KB of memory per connection and less than 2% of network overhead. Many people believe that SSL/TLS takes a lot of CPU time and we hope the preceding numbers will help to dispel that."
- Adam Langley, Google
Getting an SSL certificate used to be a cost, but that's taken care of now by https://letsencrypt.org/.
So can you recommend a mirror for them that supports SSL?
There are multiple named projects there that aren't using SSL, and I don't think it's just laziness. If you know of a way for them to use SSL mirrors for no additional cost, I'll work on getting them to switch over.
This is only true for Intel and AMD x86_64 servers that have hardware accelerated AES with the AES-NI instruction set. Software implementations of AES and the other ciphers are much, much slower than AES with hardware acceleration. RC4 was the fastest decent software cipher for a while, but that has been found to be insecure and its use is discouraged. The fastest possible replacement would probably be ChaCha20, but that cipher is not widely supported yet. The other software ciphers are very slow, and certainly wouldn't be considered as "fast yet".
Most people download software from websites using GUI browsers, while performing a checksum generally requires opening a terminal, changing directories to where the file was downloaded, and running the checksum program there. Maybe the web browser should provide a UI for doing checksums directly in the download manager. For example, each download entry could have a blank "checksum" text box where you can paste in the checksum given on the page.
> In the case where the attacked has direct control over the website then you're right, it doesn't help at all.
I was pretty sure that's the threat model we were discussing: Software authenticity.
The only way to automatically know if a piece of software is legitimate is to have a trusted public key that can verify a signature.
Also, HTTPS is implied these days. If you're not using HTTPS, you are either malicious, negligent, incompetent, or working for someone who is some or all of the above.
> If you're not using HTTPS, you are either malicious, negligent, incompetent…
Or poor. Hosting large amounts of binaries over https isn't cheap. I just priced Amazon S3 and cloudfront and for the amount of data that I serve it would cost $300 per month. That's a lot to commit for a GPL-ed binary that brings in practically zero revenue. Maybe there's a cut rate VPS out there that can handle 150GB of data and 3TB of bandwidth per month on the cheap, but I haven't found it yet.
Right. All I have to do is distribute the correct hash for my binary as a malicious software distributor because there's no authenticity verification at all, only that the bits in my binary blob match a certain pattern.
That would be a useful extension/plugin for browsers actually.
Maybe like pointed out in another reply, not for checksums but for signatures. So you just copy/paste the signature after selecting a file, and then it can verify it's validity.
Is there no such extension yet? it seems like there should be one already.
Maybe something like:
- have a database of common downloads and all their crypto info, which developers can update once they are validated
- have browser extensions that will check packages on download and alert if suspicious
You could pay for it with some sort of sponsorship from apps themselves, who have an interest in not getting compromised like this (it's terrible publicity).
>Though I think most people can't be bothered to verify the checksum on a file every time they download it.
This wouldn't help anyway. If the malicious party had access to alter the downloads (as they did here) they could just as well change the checksum shown on the page to.
>On the other hand, the Windows and OS X App Stores are awful.
Haven't used the Windows one, but what's "awful" about the OS X one? Quick, one click, installations, isolated, signed, easy updates.
Might be bad for the application developers somehow, but I don't see anything much bad about it from a user perspective -- except maybe the lack of trials. Then again I've been able to get a refund any time I bought an app that was subpar and written to Apple (that was 2 times).
In the original thread, the initial reporters specifically pointed out that the files they had downloaded did not match the checksums on the Transmission page. My guess would be that the attackers compromised a mirror, but not the web server serving up the user-visible page with the checksum.
Generally, Linux package maintainers grab the upstream source, while most of these compromises seem to be of the binaries. And, of course, the maintainers generally review the changes before publishing them
No, Linux distributions offer packages and operating systems that are the result of painstaking work in which all upstream code is reviewed, patched for any inconsistency, and often blocked from going into public archives until known bugs are fixed.
Actually, most have scripts that pull the upstream source and build new binaries without any manual intervention. It is the responsibility of the package maintainer to review every change in code.
The app made it onto the OSX App Store and the author's certs were revoked. This isn't a case of verify source, verify application. This is a case of anything can be infected and it's damn near impossible to check everything.
Transmission wasn't on the Mac App Store, though the app was signed. Apple offers developers the ability to sign their apps distributed outside the Mac App Store to certify them as an Apple-identified developer https://developer.apple.com/library/ios/documentation/IDEs/C...
As such, checking the source is still very much relevant here since this wasn't a compromised app in the Mac App Store, it's an app distributed outside it.
Linux package managers are looking like one of the only straightforward ways to distribute applications securely.
Unless you are a small independent app developer. Virtually no distribution wants to take proprietary software. And you have to package for a wide variety of different distributions.
On the other hand, the Windows and OS X App Stores are awful.
The Mac App store works pretty much effortless for me. It's sometimes a bit slow, but other than that it's pretty trivial to use.
It's not at the time of installation, but prior to updates the package management system will check signatures of the packages. (And it will only accept packages signed with your key, so the attack used against Transmission wouldn't work)
The question is whether we should trust proprietary software even if it is downloaded securely. I consider "hard to get proprietary software into the official repos" as a feature. Unfortunately it's not as hard as you make it sound in most distributions.
- The APIs exposed to Mac App Store apps are more limited (because the OS X sandbox is not completely comprehensive in what it provides). This limits the types of apps that can be sold on the store.
- There's no means of providing paid upgrades. E.g. for a major version bump, which a lot of developers rely on to keep their business afloat.
- The store interface and navigation are also much slower than the iOS counterpart.
- Recently some certificate issues rendered users unable to open their apps.
- Not 100% sure on this one: You can't download older app versions if your OS is no longer supported.
- There's no means of providing paid upgrades. E.g. for a major version bump, which a lot of developers rely on to keep their business afloat.
Apple and other do this by simply numbering the names of apps. They don't allow you to specify special "upgrade" pricing, but the effect of this was that developers no longer really have full retail pricing and everything is just set to the upgrade price.
Logic Pro 8 for instance used to retail at $499. The upgrade price was $199. Now Logic Pro X on the Mac App Store is just $199 regardless of whether you are first time user or someone who had the previous version.
- The store interface and navigation are also much slower than the iOS counterpart.
I haven't really found that the Mac Store is any slower. I've found that they are both slow.
- Not 100% sure on this one: You can't download older app versions if your OS is no longer supported.
I don't believe it will even show you newer versions of the apps as long as the developer properly specifies the minimum OS version.
There's no completely secure way, except for getting the public key directly from the developer over a trusted channel (or in person). And even that won't protect you in case the developer's keys gets compromised.
But there are a number of things that can be done:
- always verify the checksum (if available), in case the download mirror (but not the web site itself) got compromised.
- check for strange strings in the binary (use "strings" and "grep"). E.g. URLs
- scan the downloaded file on Jotti or VirusTotal.
- unpack the binary manually with 7-zip or similar if it's a self-extracting file.
- check installation scripts, build files, etc. (if applicable).
- if downloading source code, check a couple of files at random. Will most likely not protect you, but if everyone does it, it helps detecting embedded malware (or bugs) early.
- run "strace" (Linux/Unix) or "FileMon" (Windows) or similar software and log what the software does when you install and run it for the first time.
On the other hand, the Windows and OS X App Stores are awful. Linux package managers are looking like one of the only straightforward ways to distribute applications securely.