Re: "Trojan Source" (CVE-2021-42574 and CVE-2021-42694): can 'guix lint' help someway?

[Bengt Richter <bokr@bokr.com>]

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