Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • T tails
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 1,014
    • Issues 1,014
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 28
    • Merge requests 28
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • tails
  • tails
  • Issues
  • #12456
Closed
Open
Issue created Apr 18, 2017 by Dr_Whax@Dr_Whax

Biterrant attack

Originally created by @Dr_Whax on #12456 (Redmine)

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.

Related issues

  • Blocks #12476 (closed)
  • Blocks #12475 (closed)
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking