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