On Sun, 17 Apr 2005, Ingo Molnar wrote:

Date: Sun, 17 Apr 2005 16:52:32 +0200
From: Ingo Molnar <redacted>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Petr Baudis <redacted>, Simon Fowler <redacted>,
     David Lang [off-list ref], git@vger.kernel.org
Subject: Re: Re: Merge with git-pasky II.


* Linus Torvalds [off-list ref] wrote:

quoted

Almost all attacks on sha1 will depend on _replacing_ a file with a
bogus new one. So guys, instead of using sha256 or going overboard,
just make sure that when you synchronize, you NEVER import a file you
already have.

With tens of thousands (or hundreds of thousands) of objects expected in
the repository sooner or later, there's quite a selection to pick from.
Once you apply the patch, instead of the expected new file that you
reviewed and found safe, the attacker has the other object included in
the official kernel.

A dangerous object can be anything: e.g. a debugging hack that allows
arbitrary kernel-space writes. Or a known-insecure module (which since
then got fixed, but the buggy code still exists in the DB). The module
is in a single file and is self-installing (e.g. it has __init code to
register itself as some driver.)

While I agree that a hash collision is bad and certainly worth preventing
during new object creation, for it to actually implant a trojan in a build
successfully it'd have to meet even more criteria than you've layed out.
It'd have to...

  - be shadowing an object that's part of an active tree
  - provide all the public symbols the shadowed object provided so that it
    would still build and link successfully

Shadowing an object that's not part of the working tree means something on
another branch or obsoleted some time in the past is still db corruption,
but not nearly as big an issue from a trojan standpoint.

Later,
Brad