Re: Tricking peer review

[zimoun <zimon.toutoune@gmail.com>]

Hi,

On Wed, 20 Oct 2021 at 10:22, Giovanni Biscuolo <g@xelera.eu> wrote:

> I think the "final" result of this discussion should be condensed in a
> few (one?) additional paragraphs in the Contributing section of the Guix
> manual

Run “guix lint” is already listed.  What do you have in mind about more
additions?


> Well done Simon: AFAIU this is a complete analisys of the possible
> "source" attacks, or is something missing?

To my knowledge, yes it is exhaustive with the current situation about
tricking the content-addressed system.

On the top of that, it is addressed by hash functions; it is thus
vulnerable to preimage attack of such hash functions.  SWH uses SHA-1 to
address and I do not know how they address potential collisions.

For instance, the cost for SHA-1 [1] is still really expensive.  Well,
for interested reader, one can read the discussion here [2].  SHA-1 is
2^160 (~10^48.2) and compare to 10^50 which is the estimated number of
atoms in Earth.  Speaking about content-addressability, SHA-1 seems
fine.  We are speaking about content-addressability not about using
SHA-1 as hash function for security, IMHO.  It is the same situation as
Git, for instance.

The surface of attack is very low because:

 a) SWH is an archive and not a forge,
 b) a chosen-prefix attack [3] could no work if review is correctly done;
    which means run “guix lint”,
 c) an attacker has to trick the checksum (SHA-256) and the address
    (SHA-1); at various locations: Guix history (now signed), SWH,
     Disarchive-DB.

1: <https://shattered.it/>
2: <http://issues.guix.gnu.org/issue/44187#4>
3: <https://sha-mbles.github.io/>

>>> Also, just because a URL looks nice and is reachable doesn’t mean the
>>> source is trustworthy either.  An attacker could submit a package for an
>>> obscure piece of software that happens to be malware.  The difference
>>> here is that the trick above would allow targeting a high-impact
>>> package.
>>
>> I agree.
>
> I also agree (obviously) and I think this kind of attack should also be
> documented in the manual (if not already done)

Well, nothing new here, IMHO.  A distribution relies on content, i.e.,
any distribution points to that content.  Whatever the nature of the
pointing arrow (URL, Git commit, hash, etc.), the pointed material must
be carefully checked at package time; as explained by «Submitting
Patches» [4]. :-) That’s why I am advocating [5] that:

         new packages should *always* go via guix-patches, wait 15 days,
        then push if no remark.  It lets the time for the community to
        chime in.  And if not, it just slows down for 2 weeks.


4: <https://guix.gnu.org/manual/devel/en/guix.html#Submitting-Patches>
5: <https://lists.gnu.org/archive/html/guix-devel/2021-10/msg00110.html>

Cheers,
simon