Daniel Shahaf <d...@daniel.shahaf.name> writes:
> > That could happen after a public disclosure of a pair of executable
> > files/scripts where the forged version allows for remote code execution.
> > Or maybe something similar with a file format that is often stored in
> > repositories and that can be executed or used by a build script, etc.
> >
>
> Err, hang on. Your reference described a chosen-prefix attack, while
> this scenario concerns a single public collision. These are two
> different things.
A chosen-prefix attack allows finding more meaningful collisions such as
working executables/scripts. When such collisions are made public, they
would have a greater exploitation potential than just a random collision.
> Disclosure of of a pair of executable files/scripts isn't by itself
> a problem unless one of the pair ("file A") is in a repository
> somewhere. Now, was the colliding file ("file B") generated _before_ or
> _after_ file A was committed?
>
> - If _before_, then it would seem Mallory had somehow managed to:
>
> 1. get a file of his choosing committed to Alice's repository; and
>
> 2. get a wc of Alice's repository into one of the codepaths that
> assume SHA-1 is one-to-one / collission-free (currently that's the
> ra_serf optimization and the 1.15 wc status).
Not only. There are cases when the working copy itself installs the working
file with a hash lookup in the pristine store. This is more true for 1.14
than trunk, because in trunk we have the streamy checkout/update that avoid
such lookups by writing straight to the working file. However, some of
the code paths still install the contents from the pristine store by hash.
Examples include reverting a file, copying an unmodified file, switching
a file with keywords, the mentioned ra_serf optimization, and etc.
> Now, step #1 seems plausible enough. As to step #2, it's not clear to
> me how file B would reach the wc in step #2…
If Mallory has write access, she could commit both files, thus arranging for
a possible content change if both files are checked out to a single working
copy. This isn't the same as just directly modifying the target file, because
file content isn't expected to change due to changes in other files (that can
be of any type), so this attack has much better chances of being unnoticed.
If Mallory doesn't have write access, there should be other vectors, such
as distributing a pair of files (harmless in the context of their respective
file formats) separately via two upstream channels. Then, if both of the
upstream distributions are committed into a repository and their files are
checked out together, the content will change, allowing for a malicious
action.
Regards,
Evgeny Kotkov
