[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Tricking peer review
From: |
Giovanni Biscuolo |
Subject: |
Re: Tricking peer review |
Date: |
Wed, 20 Oct 2021 10:22:45 +0200 |
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
signature.asc
Description: PGP signature
- Re: Incentives for review, (continued)
- Re: Incentives for review, Jonathan McHugh, 2021/10/21
- Re: Incentives for review, Arun Isaac, 2021/10/22
- Re: Incentives for review, Jonathan McHugh, 2021/10/22
- Re: Incentives for review, zimoun, 2021/10/21
- Re: Incentives for review, Katherine Cox-Buday, 2021/10/28
- Re: Incentives for review, Vagrant Cascadian, 2021/10/21
- Re: Incentives for review, Efraim Flashner, 2021/10/24
Re: Tricking peer review,
Giovanni Biscuolo <=
patches for new packages proper workflow (Re: Tricking peer review), Giovanni Biscuolo, 2021/10/20
Re: Tricking peer review, Leo Famulari, 2021/10/20
Re: Tricking peer review, Christine Lemmer-Webber, 2021/10/25