Bug #12456

Biterrant attack

Added by Dr_Whax 2017-04-18 17:55:57 . Updated 2017-05-04 17:44:40 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Installation
Target version:
Start date:
2017-04-18
Due date:
% Done:

100%

Feature Branch:
Type of work:
Discuss
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

This is a ticket for discussion about the https://biterrant.io/ attack on bittorrent and possible eventual changes in the way we deliver files to our users.

The problem here being is that, once somebody comes up with an SHA1 collision for files in .torrent or our metadata, it could be used to deliver an .iso that doesn’t work and that counts as an attack in the current threat model. Currently, we don’t sign the .torrent file because it gets delivered over HTTPS, providing the “same security” as our website.

Things we consider:

  • The merkle tree extension (BEP-30) isn’t widely implemented, so let’s not assume it’s used.
  • An attacker that can deliver incorrent iso’s that don’t boot count as an attack. User might use something insecure instead.
  • There doesn’t seem to be any good safeguards that are not defaults in most clients or in software like `mktorrent`. Like the merkle tree extension.

Playing devils advocate, Modifying files in the compression sounds complicated, but what about the metadata of the sha1 hashes of the files. If you find a collision in that will replace it with malicious metadata of malicious files, could that be pulled off?

To sum it up: There doesn’t seem to be any safe guards at the moment for a user to receive these iso’s in a secure and/or working manner. Meaning users could potentially end up with an malicious iso or an iso that doesn’t actually boots.

In January 2017, there were 101209 downloads of the .torrent file, in comparison, the amount of downloads of the OpenPGP signature is 14782.


Subtasks


Related issues

Blocks Tails - Bug #12476: Consider updating mirror documentation to remove mentions about Bittorrent if we decide to not distribute Torrents anympre Rejected 2017-04-25
Blocks Tails - Bug #12475: Consider updating installation documentation to remove Bittorrent mentions if we decide not to distribute Bittorrent files anymore Rejected 2017-04-25

History

#1 Updated by jvoisin 2017-04-19 19:57:48

I don’t think that anyone can come with a collision on an arbitrary file: there is a difference between a pre-image attack, and a collision attack. What was achieved by Shattered (and thus by BitErrant) was a collision one.

For comparison, there is still no (feasible) way to achieve a preimage attack (let alone a second-preimage one) on md5.

To improve the security of the torrent, we could

  • sign the .torrent file, to prevent distribution of a torrent file pointing to malicious files, since as said in the ticket, currently the torrent file has the same security than the website.
  • push (even more) the users to check the integrity of the torrent-downloaded iso, for example by distributing a README file in the torrent with links to the doc, and explaining how to verify the torrent (someone would have to find a way to change the iso file and the README to backdoor the iso).

Even if we don’t implement the two proposed points, I don’t see any realistic threat model to defend against by removing the torrent file.

#2 Updated by anonym 2017-04-19 22:10:27

jvoisin wrote:
> I don’t think that anyone can come with a collision on an arbitrary file: there is a difference between a pre-image attack, and a collision attack. What was achieved by Shattered (and thus by BitErrant) was a collision one.

This clarification (and suggestion to remind myself of the nuances among hash attacks) make it shamefully obvious that we were misguided! However, there’s a plot twist! Does it make any difference that us Release Managers can use something like BitErrant to distribute a malicious ISO via BitTorrent? :) Probably not, as we already can ship modified binaries inside the Tails filesystem.

Any way, the original statement is wrong, so I removed it and toned the rest down to “we suspect that BitTorrent is not safe” until we know that we actually want to reintroduce BitTorrent again. I mean, with the history of MD5 vaguely in mind together with the “attacks only get better” mantra, shouldn’t we take SHAttered/BitErrant as signs that it’s time to worry about SHA-1 and its applications, so in fact perhaps it is time to drop BitTorrent? AFAIK there’s no clear widespread plan yet in the BitTorrent community of implementers about switching hashing algorithm, and that doesn’t bode well. Hopefully I’m wrong about this as well! :)

#3 Updated by jvoisin 2017-04-19 22:42:50

Maliciouss RM can do other easier things I guess, but it someone goes with the BitErrant-powered backdoor, s·he’ll need to modify/craft some binary portions of Tails (and this behaviour would be detected because the build process is now (almost?) reproductible). If someone can modify binary portions of Tails, there is no need to use sha1 collisions, just plant a backdoor in it.

Attacks are of course always getting better, but we still need to use cryptography at some point.
Git is using sha1 too, and I don’t think that we want to stop using it because of this ;)
Everyone moved away from SHA-1 powered certificates, because of collisions, but for git, there is no rush, since collisions won’t do much. I guess it’s the same for torrent in our case, since an attacker would need a pre-image.

In my opinion, there is no need to throw torrents away for now: “It’s time to walk, but not run, to the fire exits. You don’t see smoke, but the fire alarms have gone off.”.

#4 Updated by anonym 2017-04-20 11:20:54

jvoisin wrote:
> Maliciouss RM can do other easier things I guess, but it someone goes with the BitErrant-powered backdoor, s·he’ll need to modify/craft some binary portions of Tails (and this behaviour would be detected because the build process is now (almost?) reproductible). If someone can modify binary portions of Tails, there is no need to use sha1 collisions, just plant a backdoor in it.

Exactly! However, the way we instruct users to download and authenticate Tails with BitTorrent means that there is no further authentication of Tails than what the .torrent provides, so we RMs could distribute the good ISO to most users, and selectively distribute some bad chunks to users via BitTorrent. :)

> Attacks are of course always getting better, but we still need to use cryptography at some point.
> Git is using sha1 too, and I don’t think that we want to stop using it because of this ;)
> Everyone moved away from SHA-1 powered certificates, because of collisions, but for git, there is no rush, since collisions won’t do much. I guess it’s the same for torrent in our case, since an attacker would need a pre-image.
>
> In my opinion, there is no need to throw torrents away for now: “It’s time to walk, but not run, to the fire exits. You don’t see smoke, but the fire alarms have gone off.”.

Thanks for this insight! Better safe than sorry, but it seems there’s no “sorry” to talk about yet. So: let’s add back torrents? Any objections? Otherwise I’ll generate and upload ones for 2.12 and 3.0~beta4.

#5 Updated by Throwaway59711 2017-04-20 14:48:39

I am also in favor of using torrents again.

If you decide not to use torrents, please at least use TLS! The current download link on the download page ( https://tails.boum.org/install/download/openpgp/index.en.html ) is sent over plain-text and is far easier to modify in a simple MITM attack than in a theoretical SHA-1 attack. In the process of removing one small attack vector, a huge one was opened.

Also, if users do not seem to be downloading the OpenPGP signature, I would suggest making a list of SHA512 hashes easily available on the downloads page. Many users find verifying signatures more difficult than verifying a secure hash. The level of security may not be the same, but it’s better than users not verifying anything as the OP suggests is currently done.

#6 Updated by Anonymous 2017-04-25 10:12:04

  • related to Bug #12476: Consider updating mirror documentation to remove mentions about Bittorrent if we decide to not distribute Torrents anympre added

#7 Updated by Anonymous 2017-04-25 10:12:12

  • related to Bug #12475: Consider updating installation documentation to remove Bittorrent mentions if we decide not to distribute Bittorrent files anymore added

#8 Updated by Anonymous 2017-04-25 10:15:25

  • related to deleted (Bug #12476: Consider updating mirror documentation to remove mentions about Bittorrent if we decide to not distribute Torrents anympre)

#9 Updated by Anonymous 2017-04-25 10:15:33

  • blocks Bug #12476: Consider updating mirror documentation to remove mentions about Bittorrent if we decide to not distribute Torrents anympre added

#10 Updated by Anonymous 2017-04-25 10:16:14

  • related to deleted (Bug #12475: Consider updating installation documentation to remove Bittorrent mentions if we decide not to distribute Bittorrent files anymore)

#11 Updated by Anonymous 2017-04-25 10:16:23

  • blocks Bug #12475: Consider updating installation documentation to remove Bittorrent mentions if we decide not to distribute Bittorrent files anymore added

#12 Updated by Pyth0n 2017-04-29 10:33:42

Dr_Whax wrote:

> The problem here being is that, once somebody comes up with an SHA1 collision for files in .torrent or our metadata, it could be used to deliver an .iso that doesn’t work and that counts as an attack in the current threat model. Currently, we don’t sign the .torrent file because it gets delivered over HTTPS, providing the “same security” as our website.

In the era of antivirus/firewall software injecting bogus CA in browsers and resigning (effectively compromised) HTTPS flow, I wouldn’t call HTTPS as an ultimate security measure. I guess that’s why you GPG sign ISO file itself and publish that signature along with your public key (which itself can be malled by HTTPS interception, both the signature and the key itself, by the way). However, let’s assume that your HTTPS is secure.

Due to intended use of TAILS, a sane user should ALWAYS check the signature (that’s why the relevant subpage is called Download and verify) and - as such - would be immune to any torrent malleability. The only adverse effect of the mentioned collision attack would be a DoS attack on downloaders, resulting in a plenty damaged ISOs, as some parts of ISO would come from a legit image and other parts from a forged image. It’s cryptographically improbable, that such damaged ISO would pass SHA512 signature verification step. Even if someone forged ISO that fulfills both torrent hash and signature hash (160 bits + 512 bits = effective attack on 672-bit hash), it will still fail miserably when it comes to ISO that is blockwise random mix of forged and legit ISO.

So from my point of view, disabling torrent downloads gives no effective rise of security.

#13 Updated by intrigeri 2017-04-29 12:08:20

  • Assignee set to anonym
  • Target version set to Tails_3.0

anonym: you said you cared a lot about this issue, and you’ve been the one tracking it so far, so assigning to you so you lead the discussion to an actionable conclusion.

#14 Updated by intrigeri 2017-04-29 12:11:23

> If you decide not to use torrents, please at least use TLS!

That’s WIP: Feature #9796

#15 Updated by intrigeri 2017-04-29 12:13:59

> In the era of antivirus/firewall software injecting bogus CA in browsers and resigning (effectively compromised) HTTPS flow, I wouldn’t call HTTPS as an ultimate security measure.

The design goal of our current installation assistant is to provide TLS-level download security to all users, including non technical ones (and with a pinned CA for the main download method). Expert users can do OpenPGP on top if they want to. If anyone wants to discuss potential improvements to this, good! But please do so on another, dedicated ticket, as the discussion on this ticket shall be based on the currently agreed upon and implemented design :)

#16 Updated by intrigeri 2017-04-29 12:17:31

After reading this discussion, my current conclusion is that we’ve totally misunderstood the impact of the attack, and that the security of our bittorrent downloads is still good enough. So I propose we revert to what we did before the 2.12 release, i.e. ship Torrents, for the foreseeable future when 2nd pre-image attacks are not realistic yet.

#17 Updated by webdawg 2017-05-04 02:44:08

So, I am grabbing tails at 83kb a sec from some of these mirrors. I get it guys but:

I would think that even though the torrent protocol has some verification in it, its primary purpose was to spread information across the internet via p2p, and the verification was put in there to give assurance of accurate information transfer. A checksum against corruption during data transfer.

If you want people to verify it w/ GPG/whatever, encourage them through the flow of the site/ download.

Download sig file, then below, download torrent with a statement:

“Torrent is just a distribution method, and all though its creators have made some level of effort to make sure you will receive the correct file, we think (link to this issue) that it has flaws. If you use torrent YOU STILL MUST VERIFY THE SIGNATURE.”

Insert command line instructions to verify here
Insert other instructions to verify here

I mean, you should just disable any level of downloading at this point because you are just arguing if x protocol is better then x protocol, which at this point it is pretty clear that most if not all of it is insecure.

I suppose we could just use this in the end: https://en.wikipedia.org/wiki/IP_over_Avian_Carriers

#18 Updated by webdawg 2017-05-04 02:45:53

Also, you specify torrent download vs pgp download. I wonder how many people download just to help you seed and never actually use the file.

#19 Updated by anonym 2017-05-04 17:44:40

  • Status changed from Confirmed to Resolved
  • Assignee deleted (anonym)
  • % Done changed from 0 to 100
  • QA Check set to Pass

webdawg wrote:
> I get it guys but:

I don’t think you did; the consensus is to re-introduce torrents, which is what you want.

In fact, I just added the .torrent option back! Please help us seeding! :)