3 ms·

There was a discussion about this recently saying that it was highly unlikely. All the source was in Git and every git commit references the previous commit, ma

by jeresig 13y ago

There was a discussion about this recently saying that it was highly unlikely. All the source was in Git and every git commit references the previous commit, making it highly challenging to modify an old commit without also modifying the commit id. More details: http://archive.is/Khq7R http://archive.is/Khq7R

rgbrenner 13y ago
Yes, it's unlikely they modified the source in git.. But it's possible they were able to download a copy and modify it locally... Possibly adding comments to document certain blocks of code.. Or adding unofficial patches for zfs support... Or worse..
- adamnemecek 13y ago
  Isn't that against the Geneva Convention?
- SimHacker 13y ago
  Like enabling ReiserFS??!
jeffreyg 13y ago
whoosh :)
deleted 13y ago
[deleted]
joeyh 13y ago
Here's how to do it: 1. Contribute a driver to the kernel. A network driver would be ideal, but any driver will do. Include a binary firmware blob, because including binary firmware blobs in drivers is how linux kernel devs roll (or how they used to roll). When creating the binary firmware blob, use a SHA1 preimage attack to actually create two versions with the same SHA. One is benign, and one runs your back door. 2. Root git server. Replace object containing firmware blob with the alternate version. This attack should be detectable by comparing blobs from old git clones with blobs from new ones, using a hash that has better preimage resistance than does SHA1. There are other ways to get your SHA1 colliding binary blob into a git commit in ways that are unlikely to be noticed. I demonstrated one (without actual SHA1 preimage attack) here: http://github.com/joeyh/supercollider http://github.com/joeyh/supercollider But a binary firmware blob is pretty much ideal.
- rgbrenner 13y ago
  except there are no practical preimage attacks on sha1
  - meowface 13y ago
    Right. His comment reads as "ok, do all these simple things then just put in your backdoor but make sure it has the same SHA1 hash as something benign, and that's it!"

by jeresig 13y ago

rgbrenner 13y ago

Yes, it's unlikely they modified the source in git.. But it's possible they were able to download a copy and modify it locally... Possibly adding comments to document certain blocks of code.. Or adding unofficial patches for zfs support... Or worse..

adamnemecek 13y ago
Isn't that against the Geneva Convention?
SimHacker 13y ago
Like enabling ReiserFS??!

jeffreyg 13y ago

whoosh :)

deleted 13y ago

[deleted]

joeyh 13y ago

Here's how to do it: 1. Contribute a driver to the kernel. A network driver would be ideal, but any driver will do. Include a binary firmware blob, because including binary firmware blobs in drivers is how linux kernel devs roll (or how they used to roll). When creating the binary firmware blob, use a SHA1 preimage attack to actually create two versions with the same SHA. One is benign, and one runs your back door. 2. Root git server. Replace object containing firmware blob with the alternate version. This attack should be detectable by comparing blobs from old git clones with blobs from new ones, using a hash that has better preimage resistance than does SHA1. There are other ways to get your SHA1 colliding binary blob into a git commit in ways that are unlikely to be noticed. I demonstrated one (without actual SHA1 preimage attack) here: http://github.com/joeyh/supercollider http://github.com/joeyh/supercollider But a binary firmware blob is pretty much ideal.

rgbrenner 13y ago
except there are no practical preimage attacks on sha1
- meowface 13y ago
  Right. His comment reads as "ok, do all these simple things then just put in your backdoor but make sure it has the same SHA1 hash as something benign, and that's it!"