Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Linux Backdoor Attempt of 2003 (2013)

freedom-to-tinker.com

Post reply on HN
Print view View original

141–144 of 144 posts

Re: The Linux Backdoor Attempt of 2003 (2013)

#141

Post by asveikau »

asddubs wrote: post #76
FartyMcFarter wrote: post #58

Earlier quoted context omitted.

Unless the first character was null, in which case it would be ignored by the condition... Also, you don't need to dereference a pointer in order to increase it. The grandparent post's code is just nonsensical.

haha, I was genuinely asking if it made sense, I don't usually do C. Maybe it helped illustrate that the code is too clever for me, at least. e: I submit my revised code: do { *dst = *src; src++; dst++; } while(*(dst - 1));

Looking at src[-1] would work but feels like poor form. My advice is stop trying to make do ... while work here, it isn't looking good.

I feel like more idiomatic iterating through a string tends to loop on src not being a terminator.

    while (*src)
    {
       *dst = *src;
       ++src;
       ++dst;
    }

    *dst = '\0';
I feel like this is idiomatic C but needlessly verbose. Most people would combine the increment with the assignment. And most people would recognize putting it in the while condition as a common strcpy.

Re: The Linux Backdoor Attempt of 2003 (2013)

#142

Post by db48x »

flingo wrote: post #135
db48x wrote: post #123

Earlier quoted context omitted.

That's true of a CRC code, but hashes are a lot harder to break. Git hashes each file, and puts those hashes into a tree object, like a directory listing. Then it hashes the trees, recursively back up to the root of the repository. Finally the hash of the root tree is put in the commit object, and the commit object is hashed. Thus the two places you can put additional data to be hashed are the file contents (either i…

I'm still not following why it'd require so much data? I thought the goal was to have the commit hash collide with an existing commit hash, is that not enough? I looked around, and it seems like the right place to hide the added data is in the "trailer" section of the commit. It's where signed-off-by lives and is used to generate the commit hash. You might want to come up with a plausible reason for random data to go…

In a CRC-style code, you're essentially adding up all the bytes and letting it overflow the counter, so that the counter is a fixed size (usually 16 or 32 bits). Then you add a few more bytes, exactly the same size as the counter, so that the data bytes plus the extra bytes add up to zero. The extra bytes are delivered along with the data bytes, so that the recipient can repeat the calculation and verify that the total is still zero. If you modify the data, it is trivial to recalculate the CRC code so that the total is still zero.

Hashes are much, much more complex, and they're non-linear. Each bit of the hash output is intended to depend on every single bit of the input, so that changing a single bit in the input creates a radically different hash output.

In a paper published this year, https://eprint.iacr.org/2020/014.pdf, the authors Gaëtan Leurent and Thomas Peyrin changed the values of 825 bytes out of a 1152 byte PGP key in order to generate a new key with the same signature (aka, the same hash). It only cost about $45k, too.

Re: The Linux Backdoor Attempt of 2003 (2013)

#143

Post by eru »

tomxor wrote: post #70
Cthulhu_ wrote: post #63

Earlier quoted context omitted.

SHA1 is close to being broken, but it's not there yet, and Git will be migrating to a better algorithm. That said, if you could rewrite an older commit, the change would only be applied in a fresh clone, right?

> That said, if you could rewrite an older commit, the change would only be applied in a fresh clone, right? I think so, assuming the fetch algorithm is using the hashes to get the deltas which I think it does. I'm not sure about CVS but with GIT rewriting a _previous_ commit _object_ itself with different blobs but making the commit object itself have the _same_ hash by messing with it's comment wouldn't cause any d…

Yes, I would assume that most git repositories would want to re-hash all old commits when SHA1 gets replaced.

For backwards compatibility, I suspect we'll add the new hash and keep SHA1 around, unless you specifically disable SHA1.

Re: The Linux Backdoor Attempt of 2003 (2013)

#144

Post by woodrowbarlow »

pyuser583 wrote: post #138

How would git have handled the same issue? I imagine if Linus pushed to the remote repo, it would have said “your repo isn’t up to date”. But AFAIK, it doesn’t have the same sort of built in checksum checkers. If an attacker signed the commit insecurely, would git complain? Can you set git to require PGP signatures? Probably.

each commit's id is an integrity hash of the repository at the time of commit. git doesn't provide access control; it relies on access controls built-into whichever transport mechanisms you choose to enable (https, ssh, etc).

you can sign commits with PGP signatures and with hooks, you can reject commits that aren't signed. i believe maintainers sign commits in the linux repo.

Post reply on HN