5 ms·

What are the ramifications if this is what happened? I strongly suspect they were able to get a copy of the kernel source code... They could be doing anything

What are the ramifications if this is what happened? I strongly suspect they were able to get a copy of the kernel source code... They could be doing anything with it.. Porting it to a new platform.. Compiling it with unsafe GCC flags.. Or worse..

spangled 13y ago
This reminds me of a friend's response to the idea that the TouchID in the new iphone could be a way for the NSA to get your fingerprints: "Just imagine the shitstorm if they put a camera in there. Or a microphone."
- r4pha 13y ago
  Or a GPS.
- ris 13y ago
  There's no good way yet to uniquely identify a person based on a (dodgy) picture of them or sample of their voice. Whereas fingerprints are used for this daily* and a quickly searchable database of these (or just their "hashes") would be incredibly useful to _somebody_. *I'm not raising the issue of whether they _should_ be or not here, just that they are.
  - contingencies 13y ago
    There's no good way yet to uniquely identify a person based on a (dodgy) picture of them or sample of their voice Surely this is sarcastic. We can easily identify with great certainty from a relevant set... as Facebook does, for instance. You have a relevant set if you are many governments (the local government, and in many cases Israel via AMDOCS and its intelligence allies - primarily the US, but in some cases possibly their intelligence allies) or a motivated attacker (eg. with an insider, or hiring an insider via a private investigation firm), because you have the device call/messaging/physical location records from which to cross-match. Even if it's a land-line. You also have easy access to additional voice data (voicemail recording, 'this call may be recorded' records at large companies such as banks or wings of government, etc.). Public data sets on non-secret government telephone interception frequency even in 'free-ish' countries like Australia suggest extremely broad cultures around acceptable collection. (For .au I read a raw statistics report I can't seem to relocate recently, but http://www.smh.com.au/technology/technology-news/be-careful-she-might-hear-you-20120924-26h6r.html http://www.smh.com.au/technology/technology-news/be-careful-... is a good overview.)
deleted 13y ago
[deleted]
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.
woah 13y ago
The people need an answer. Does the NSA have a copy of the linux source code or not??!

spangled 13y ago

This reminds me of a friend's response to the idea that the TouchID in the new iphone could be a way for the NSA to get your fingerprints: "Just imagine the shitstorm if they put a camera in there. Or a microphone."

r4pha 13y ago
Or a GPS.
ris 13y ago
There's no good way yet to uniquely identify a person based on a (dodgy) picture of them or sample of their voice. Whereas fingerprints are used for this daily* and a quickly searchable database of these (or just their "hashes") would be incredibly useful to _somebody_. *I'm not raising the issue of whether they _should_ be or not here, just that they are.
- contingencies 13y ago
  There's no good way yet to uniquely identify a person based on a (dodgy) picture of them or sample of their voice Surely this is sarcastic. We can easily identify with great certainty from a relevant set... as Facebook does, for instance. You have a relevant set if you are many governments (the local government, and in many cases Israel via AMDOCS and its intelligence allies - primarily the US, but in some cases possibly their intelligence allies) or a motivated attacker (eg. with an insider, or hiring an insider via a private investigation firm), because you have the device call/messaging/physical location records from which to cross-match. Even if it's a land-line. You also have easy access to additional voice data (voicemail recording, 'this call may be recorded' records at large companies such as banks or wings of government, etc.). Public data sets on non-secret government telephone interception frequency even in 'free-ish' countries like Australia suggest extremely broad cultures around acceptable collection. (For .au I read a raw statistics report I can't seem to relocate recently, but http://www.smh.com.au/technology/technology-news/be-careful-she-might-hear-you-20120924-26h6r.html http://www.smh.com.au/technology/technology-news/be-careful-... is a good overview.)

deleted 13y ago

[deleted]

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.

woah 13y ago

The people need an answer. Does the NSA have a copy of the linux source code or not??!