Re: Tricking peer review

[Giovanni Biscuolo <g@xelera.eu>]

[-- Attachment #1: Type: text/plain, Size: 2735 bytes --]

Hi Simon and Ludovic,

very interesting thread, thank you!

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

zimoun <zimon.toutoune@gmail.com> writes:

[...]

>  - url-fetch: the attacker has to introduce the tarballs into SWH.
>    There is not so much means, from my understanding: SWH ingests
>    tarballs via loaders, for instance gnu.org or sources.json or
>    debian.org etc. Therefore the attacker has to introduce the malicious
>    code to these platforms.
>
>  - url-fetch without metadata (as your example), indeed, the reviewer
>    could be abused; mitigated by the fact that “guix lint” spots the
>    potential issue.
>
>  - url-fetch with metadata: the attacker have to also corrupt
>    Diasarchive-DB.   Otherwise, the tarball returned by SWH will not
>    match the checksum.
>
>  - svn-fetch, hg-fetch, cvs-fetch: no attack possible, yet.
>
>  - git-fetch: it is the *real* issue.  Because it is easy for the
>    attacker to introduce malicious code into SWH (create a repo on
>    GitHub, click Save, done).  Then submit a package using it as you
>    did.  It is the same case as url-fetch without metadata but easier
>    for the attacker.  It is mitigated by “guix lint”.

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

> That’s said, if I am an attacker and I would like to corrupt Guix, then
> I would create a fake project mimicking a complex software.  For
> instance, Gmsh is a complex C++ scientific software.  The correct URL is
> <https://gmsh.info> and the source at
> <https://gitlab.onelab.info/gmsh/gmsh>.  Then, as an attacker, I buy the
> domain say gmsh.org

or onelab.org, onehab.info and also set up a https://onehab.info web
site identical to the legitimate one just to trick people

> and put a malicious code there.  Last, I send for
> inclusion a package using this latter URL.  The reviewer would be
> abused.
> That’s why more eyes, less issues. :-)

I agree, but eyes should also be aware of this class of possible attacks

>> 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)

[...]

Thanks! Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]