Re: Tricking peer review

[zimoun]

Hi,

On Fri, 15 Oct 2021 at 20:54, Ludovic Courtès <ludovic.courtes@inria.fr> wrote:

> --8<---------------cut here---------------start------------->8---
> $ guix build -f /tmp/content-addressed.scm  -S --check 
> La jena derivaĵo estos konstruata:
>    /gnu/store/nq2jdzbv3nh9b1mglan54dcpfz4l7bli-sed-4.8.tar.gz.drv
> building /gnu/store/nq2jdzbv3nh9b1mglan54dcpfz4l7bli-sed-4.8.tar.gz.drv...
>
> Starting download of 
> /gnu/store/1mlpazwwa2mi35v7jab5552lm3ssvn6r-sed-4.8.tar.gz
> From https://ftpmirror.gnu.org/gnu/zed/sed-4.8.tar.gz...
> following redirection to 
> `https://mirror.cyberbits.eu/gnu/zed/sed-4.8.tar.gz'...
> download failed "https://mirror.cyberbits.eu/gnu/zed/sed-4.8.tar.gz"; 404 "Not 
> Found"
>
> [...]
>
> Starting download of 
> /gnu/store/1mlpazwwa2mi35v7jab5552lm3ssvn6r-sed-4.8.tar.gz
> From 
> https://archive.softwareheritage.org/api/1/content/sha256:58e6751c41a7c25bfc6e9363a41786cff3ba5709cf11d5ad903cf7cce31cc3fb/raw/...
> downloading from 
> https://archive.softwareheritage.org/api/1/content/sha256:58e6751c41a7c25bfc6e9363a41786cff3ba5709cf11d5ad903cf7cce31cc3fb/raw/
>  ...
>
> warning: rewriting hashes in 
> `/gnu/store/mgais6lk92mm8n5kyx70knr11jbwgfhr-sed-4.8.tar.gz'; cross fingers
> successfully built 
> /gnu/store/nq2jdzbv3nh9b1mglan54dcpfz4l7bli-sed-4.8.tar.gz.drv
> --8<---------------cut here---------------end--------------->8---

The message can be even more “spottable” than the URL
’archive.softwareheritage.org’ if the vault requires a cooking.  One
will see «SWH vault: requested bundle cooking, waiting for
completion...» or «SWH vault: retrying...».

Yeah, it is hidden with the option ’v0’ but it is the user’s
responsibility to check, IMHO.

> It’s nothing new, it’s what I do when I want to test the download
> fallbacks (see also ‘GUIX_DOWNLOAD_FALLBACK_TEST’ in commit
> c4a7aa82e25503133a1bd33148d17968c899a5f5).  Still, I wonder if it could
> somehow be abused to have malicious packages pass review.

Yes, it is nothing new.  Somehow, it is an issue with any
content-addressed system.  Here, we need to split the issue depending on
the origins:

 - 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”.

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

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

> On the plus side, such an attack would be recorded forever in Git
> history.

I agree again. :-)

> All in all, it’s probably not as worrisome as it first seems.  However,
> it’s worth keeping in mind when reviewing a package.

I agree with a minor comment.  From my opinion, not enough patches are
going via guix-patches and are pushed directly.

For instance, the «Commit policy» section says «For patches that just
add a new package, and a simple one, it’s OK to commit, if you’re
confident (which means you successfully built it in a chroot setup, and
have done a reasonable copyright and license auditing).»

And from my point of view, 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.

Cheers,
simon