SoylentNews is people
SoylentNews
If you downloaded Mint Cinnamon today (for versions of "today" that include February 20th, 2016) you should immediately check the MD5 checksum. Blog Entry here.
From Clem:
We were exposed to an intrusion today. It was brief and it shouldn't impact many people, but if it impacts you, it's very important you read the information below.
Hackers made a modified Linux Mint ISO, with a backdoor in it, and managed to hack our website to point to it.
As far as we know, the only compromised edition was Linux Mint 17.3 Cinnamon edition.
If you downloaded another release or another edition, this does not affect you. If you downloaded via torrents or via a direct HTTP link, this doesn't affect you either.
Finally, the situation happened today, so it should only impact people who downloaded this edition on February 20th.
Apparently the hacked ISOs are hosted on 5.104.175.212 and the backdoor connects to absentvodka.com. Both lead to Sofia, Bulgaria, and the name of 3 people over there.
The comment thread suggests that the ISOs are showing up in other places, and that the Mint site may still not be entirely secure.
(Score: 0, Informative) by Anonymous Coward on Sunday February 21 2016, @03:33PM
You're doing it wrong, bro. Read up:
http://www.mathstat.dal.ca/~selinger/md5collision/ [mathstat.dal.ca]
https://en.wikipedia.org/wiki/MD5#Security [wikipedia.org]
(Score: 0, Flamebait) by Anonymous Coward on Sunday February 21 2016, @03:52PM
1. sign all releases with GPG.
2. switch to sha512 & whirlpool checksums
(Score: 0, Troll) by Anonymous Coward on Sunday February 21 2016, @05:31PM
Granted I know next-to-nothing about crypto, but provided you use a decent signing key this seems sound advice.
Am I missing something?
(Score: 0) by Anonymous Coward on Sunday February 21 2016, @05:55PM
Granted I know next-to-nothing about Marty, but provided it is decent advice a silly forced-subject seems irrelevant.
Again, am I missing something? Is the advice intentionally wrong?
(Score: 2) by Pino P on Sunday February 21 2016, @05:56PM
But how does a user securely obtain the public key of the publisher? MIT's PGP key server does not support HTTPS [noncombatant.org], which is one of the factors making it easy for trojaned PuTTY [helpnetsecurity.com] to spread.
(Score: 0) by Anonymous Coward on Sunday February 21 2016, @06:45PM
Thanks, that was an interesting read.
It seems key signing parties really are worth the effort.
(Score: 2) by Pino P on Monday February 22 2016, @09:20PM
It seems key signing parties really are worth the effort.
With respect to the OpenPGP web of trust and key signing parties, I've always wondered about two things. The first is where users of OpenPGP applications are supposed to find the money for air travel in order to get their keys signed by people living in faraway cities. The second is how the trust implied by the binary relation "Alice signed Bob's key" can be transitive. Just because I can vouch for the identity of somebody I have met at a key signing party doesn't mean I can vouch for that person's ability to vouch for other people's identities. This is why X.509 certificates (RFC 5280 [ietf.org]) have the cA bit in the basic constraints to warn people relying on the certificate that its subject is not itself a certificate authority.
(Score: 2) by Fnord666 on Sunday February 21 2016, @07:10PM
You use some sort of "out of band" mechanism to validate the fingerprint of the associated public key. Now whether the publisher knows how to do that or is willing to give you the time of day is a different story.
(Score: 2) by Pino P on Monday February 22 2016, @09:10PM
some sort of "out of band" mechanism
And this is where the argument turns into a handwave. Can you recommend such an "out of band" mechanism that doesn't involve either the CA racket (X.509) or air travel (OpenPGP web of trust)?
(Score: 2) by Fnord666 on Thursday February 25 2016, @04:25PM
A good point. A phone call to the entity in question (not using a phone number you got from the same web page as the download!!) would be one way. A PGP signed email reply from the entity in question, where the public key has been published for a number of years on a public key database is another. My own efforts trying to get a valid fingerprint from someone has met with limited success as well.
(Score: 2) by opinionated_science on Sunday February 21 2016, @07:11PM
I have also wondered this - hence you nearly always need to be vigilant. I think debian are more careful, but....
It has occurred to me that PGP fingerprints could be forged using MITM, so I'm curious as to why the FOSS movement doesn't think this serious?
(Score: 0) by Anonymous Coward on Sunday February 21 2016, @07:33PM
Because most people consider hard-to-explain-without-jargon threats to be loony paranoia until it either affects them, or someone they know who's in a similar position to them.
Remember that most people think the measure of password strength is whether their coworkers will bother to guess it by hand, thus people think their pets name ("joey") is perfectly secure since "why would they think it's my dogs name? why would they bother?"
(Score: 3, Informative) by frojack on Sunday February 21 2016, @09:30PM
PGP fingerprints could be forged using MITM, so I'm curious as to why the FOSS movement doesn't think this serious?
Because its very difficult to pull off a MITM attack against the entire world simultaneously which will go un-noticed.
I keep signing stuff (packages, email, etc) using my valid (private) key, but some mitm substitutes a different public key, and all of a sudden my emails are won't validate, my packages won't validate, and alarms sound and people start checking. Its very tricky to pull off a MITM attack against a properly signed package or even a signed email.
No, you are mistaken. I've always had this sig.
(Score: 3, Interesting) by opinionated_science on Sunday February 21 2016, @10:23PM
well I am using debian, which doesn't sign by default. I used to use OpenSuse which did.
Since the Snowden revelations, I am surprised paranoia is not running at overload. Add the likelihood of backdoors at various levels of the hw/sw stack , the one place we can add security is the open source packages we install!!!
But then we have that old compiler problem too...;-)
Good Security is *HARD*. A lesson I feel a complete beginner at...
(Score: 3, Interesting) by frojack on Sunday February 21 2016, @11:08PM
I try to avoid Debian based distros just because you never know when they are going to erupt into another cat fight.
But in checking exactly one random package I see that things are signed as well checksumed at sign-in
( see https://packages.qa.debian.org/c/claws-mail/news/20160126T114928Z.html [debian.org] ).
But I haven't gone rooting around in their outbound distro source or binary repositories to see if that
persists all the way to the end user.
No, you are mistaken. I've always had this sig.
(Score: 2) by gottabeme on Tuesday February 23 2016, @07:11AM
well I am using debian, which doesn't sign by default.
What? Debian has been signing its repos for many years. Maybe you need to read this: https://www.debian.org/doc/manuals/securing-debian-howto/ch7 [debian.org] Scroll down to "7.5 Package signing in Debian".
(Score: 3, Interesting) by frojack on Sunday February 21 2016, @09:19PM
But how does a user securely obtain the public key of the publisher?
Securely in this case only means "valid", it doesn't mean obtained via encrypted channels, which is not necessary. Public keys are not secret.
Public keys are posted in a lot of different places, keyservers all over the world, on web pages, in email footers, etc.
If someone wants to substitute their own key for someone elses key so that they can sign backdoored software packages, they have to create a new key, sign with their private key, publish the new public key to keyservers, wait for it to propagate, then, (and only then) hack the web servers where the public keys are often displayed and downloadable.
All of these things have to be done in sequence, and in the meantime everyone's existing copy of the real public key will suddenly no longer work.
This is why you should sign your email routinely, because knowledgeable people will notify you if your key fails validation, as such validation is built into mail readers or plugins thereto.
As for other people's keys, You fetch them once and leave it in your key storage. and once in a while have it check against the keyservers.
You be very careful about accepting a new key that doesn't contain a long list of signatures, especially when dealing with software distros and important stuff.
No, you are mistaken. I've always had this sig.
(Score: 2) by Pino P on Monday February 22 2016, @09:37PM
But how does a user securely obtain the public key of the publisher?
Securely in this case only means "valid", it doesn't mean obtained via encrypted channels, which is not necessary. Public keys are not secret.
Though the channel through which a public key is obtained need not be private, it still needs to be tamper-evident. HTTPS is the best known tamper-evident channel included with mainstream operating systems. Cleartext HTTP is not.
If someone wants to substitute their own key for someone elses key so that they can sign backdoored software packages, they have to create a new key, sign with their private key, publish the new public key to keyservers, wait for it to propagate, then, (and only then) hack the web servers where the public keys are often displayed and downloadable.
All of these things have to be done in sequence
A sufficiently patient attacker can certainly do so, especially if it is an ISP- or state-level actor that can proxy all of the victim's cleartext HTTP connections.
As for other people's keys, You fetch them once
So how would the user of PuTTY fetch the PuTTY key once while ensuring that the keyserver from which the key is fetched isn't being maliciously proxied?
You be very careful about accepting a new key that doesn't contain a long list of signatures, especially when dealing with software distros and important stuff.
My reply to this sentence depends on how you define "a long list of signatures". If you just count other keys that sign the developer's key, it is vulnerable to a Sybil attack [wikipedia.org] in which the attacker generates a large number of keypairs, each of which signs the key used to sign the malware. If you mean the existence of one or more relatively short paths in the web of trust from oneself to the developer, then how would a legitimate new developer go about getting his key signed widely without traveling to key signing parties in foreign countries? See my reply to maxwell demon [soylentnews.org].
(Score: 3, Interesting) by frojack on Monday February 22 2016, @10:00PM
1) Tamper evidence is obvious, because the key doesn't work if tampered with. (besides, if you still believe in https you are hopelessly delusional: https://www.eff.org/deeplinks/2011/10/how-secure-https-today [eff.org] )
2) patience isn't part of the equation. There is a very short window of opportunity in which the key has propagated (usually happens within 20 minutes of key publishing), an when people start noticing there is an un-signed-un-trusted key in the key servers with their name on it. If you wait longer to publish your bogus ISO, it will be discovered. If you publish right away, no one will be able to check the signature in preparation for installing it.
Notice how long it took for Mint to detect this fraud. Mere hours, and the word is out.
3) its not sufficient to proxy a key server, you have to proxy ALL of them, because the work as a pool, and the one that gets queried is not predictable. Then, you have to convince someone to use a URL that clearly does not match the expected domain.
4) It probably doesn't need to be a long list, but it should to be a populated list. Most people don't due this level of cross checking, but it helps.
Tools for doing this are common, but anyone using Putty might never notice.
No, you are mistaken. I've always had this sig.
(Score: 2) by Pino P on Monday February 22 2016, @10:37PM
There is a very short window of opportunity in which the key has propagated (usually happens within 20 minutes of key publishing), an when people start noticing there is an un-signed-un-trusted key in the key servers with their name on it.
Provided the program signed with the key has a sufficient audience of highly knowledgeable users.
its not sufficient to proxy a key server, you have to proxy ALL of them
Which an ISP-level actor is certainly capable of doing to one or more of its subscribers.
Then, you have to convince someone to use a URL that clearly does not match the expected domain.
If you register foobarcdn.com then you can social engineer people into thinking linuxmint.foobarcdn.com is part of the new mirror network that Linux Mint is using.
Even then, PKI practices that work for a major Linux distribution might not work for a relatively new application with one or a few otherwise professionally unknown developers.
(Score: 2) by TheLink on Monday February 29 2016, @05:08AM
But how does a user securely obtain the public key of the publisher?
Doesn't matter in practice. If the past 9 releases over X years have been signed by the same key and nobody including the releasers themselves have been making noises then when the 10th release is signed by the same key then it's more likely to be as OK as the past releases.
In contrast this logic cannot apply if you use SHAx or MD5. Since hackers could often also tamper with the page listing the hashes.
Of course even then as this incident has shown even if you are using SHAx the lower security usually doesn't matter that much in practice - it doesn't go hidden for long.
The real problems are how they got hacked in the first place. Most organizations will have the same weaknesses and vulnerabilities to being pwned if not more. The bulk of them don't really get pwned by tampered ISOs, they get pwned by running forum software that's full of holes or by social engineering, getting spearphished etc.
(Score: 2) by Pino P on Monday February 29 2016, @03:45PM
The "key continuity" model could work for something long established like PuTTY. But how would it work for a new application?
(Score: 2) by TheLink on Tuesday March 01 2016, @06:13AM
And if it takes NewAppVendor 1 year to detect and announce that the released NewApp was actually signed by a malicious party's GPG key, then perhaps people should stop trusting NewAppVendor and NewApp so much and avoid using NewApp and other stuff by NewAppVendor.
People who care about security wouldn't have placed that much trust in PuTTY when it first started.
(Score: 4, Informative) by darkfeline on Monday February 22 2016, @01:05AM
No, you're not approaching this problem correctly.
If the hackers could change the links to the ISOs, why couldn't they change the MD5 sums as well? No need to look for collisions or anything, just link the MD5 for your backdoored ISO.
This is why you use PGP. Even if they signed the ISOs with their private key, all sorts of warning bells will go off. Missing signatures, signature verification not working, etc.
For example, if Mint's master PGP public key were signed by twenty Mint devs, the attacker would have to compromise the private keys of all twenty Mint devs plus Mint's server to mount a credible attack.
Join the SDF Public Access UNIX System today!
(Score: 0) by Anonymous Coward on Monday February 22 2016, @09:34PM
The approach is Linux Mint's. The choice of MD5 is, as you elucidate, one of several questionable decisions.