all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Bengt Richter <bokr@bokr.com>
To: Leo Famulari <leo@famulari.name>
Cc: guix-devel@gnu.org
Subject: Re: "Trojan Source" (CVE-2021-42574 and CVE-2021-42694): can 'guix lint' help someway?
Date: Mon, 1 Nov 2021 16:04:00 +0100	[thread overview]
Message-ID: <20211101150400.GA11627@LionPure> (raw)
In-Reply-To: <YX/t1J8Z9WNmpofs@jasmine.lan>

Hi,

On +2021-11-01 09:38:28 -0400, Leo Famulari wrote:
> On Mon, Nov 01, 2021 at 12:30:38PM +0100, Giovanni Biscuolo wrote:
> > as probably many of you have discovered, today was announced two new
> > vulnerabilities that exploits the "bidirectional override" Unicode
> > codepoints feature, making it possible to hide malicious source code in
> > comments and literal strings /if/ the code review tool (e.g. editor)
> > does not show this.
>  
> We need to check our own Git repository history for the tricky
> codepoints.
> 
> > Is there a way for "guix lint" to check for the listed (other?)
> > "dangerous" codepoints and warn code reviewers?
> 
> Yeah, we could implement this. It might be expensive but one has to
> unpack the source code anyways.
> 
> However, I think that this attack is, in general, not within the scope
> of Guix's security model, because:
> 
> 1) Guix implicitly trusts the source code that it fetches from upstream.
> 
> 2) Guix explicitly fetches the source code from upstream — Guix
> committers do not provide a copy of the upstream code (of unprovable
> provenance) as they do in other distros.
> 
> If an attacker can make malicious modifications to the code distributed
> by an upstream project, it's not relevant to Guix if they use homoglyphs
> or a buffer overflow. Guix developers do not inspect upstream source
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> code for vulnerabilities.
  ^^^^^^^^^^^^^^^^^^^^^^^^
>

... but: they do become aware of such vulnerabilities, and
could e.g. manually append a line to a blacklist,
hash-identifying upstream files to avoid their further use
by guix, directly or in dependencies.

IOW, ISTM the trusting of upstream should not be
unconditional, and trust policy implementation should make
possible instantly effective (i.e., on blacklist update)
firewalling of guix users from further downloading of the
tainted files, and hopefully automatic identification of
past potentially corrupting uses.

I imagine some developers might want to allow downloading
blacklisted files e.g. to test workarounds etc, so some
--allow-blacklisted=foofile,barfile,... option might be
needed, but the casual client installing a guix package
should be protected.

In the latter case, maybe an automatic substitute for the
backlisted file could be provided that would generate
informative hints when used in a build instead of aborting
the whole thing. A flag in the blacklist line might be a way
to select alternative automated actions?

> What do others think?
>

-- 
Regards,
Bengt Richter


  reply	other threads:[~2021-11-01 15:04 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-01 11:30 "Trojan Source" (CVE-2021-42574 and CVE-2021-42694): can 'guix lint' help someway? Giovanni Biscuolo
2021-11-01 13:38 ` Leo Famulari
2021-11-01 15:04   ` Bengt Richter [this message]
2021-11-09 17:05 ` Ludovic Courtès
2021-11-15 17:20   ` zimoun
2021-11-16 10:06   ` Giovanni Biscuolo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211101150400.GA11627@LionPure \
    --to=bokr@bokr.com \
    --cc=guix-devel@gnu.org \
    --cc=leo@famulari.name \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.