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

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

[Giovanni Biscuolo]

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

Hello,

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.

The details are published here: https://www.trojansource.codes/

Also see related CVEs:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-42574
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-42694

I know that mitigations and patching of compilers and interpreters must
be done upstream and not much can be done by Guix, but I'm asking /if/
Guix could help code reviewers enhancing its lint function.

For example, the Rust security advisory for rustc [1] states:

--8<---------------cut here---------------start------------->8---

## Mitigations 

[...] If you can't upgrade your compiler version, or your codebase also
includes non-Rust source code files, we recommend periodically checking
that the following codepoints are not present in your repository and
your dependencies: U+202A, U+202B, U+202C, U+202D, U+202E, U+2066,
U+2067, U+2068, U+2069.

## Timeline of events 

* 2021-07-25: we received the report and started working on a fix. 
* 2021-09-14: the date for the embargo lift (2021-11-01) is communicated to us. 
* 2021-10-17: performed an analysis of all the source code ever published to 
crates.io to check for the presence of this attack. 
* 2021-11-01: embargo lifts, the vulnerability is disclosed and Rust 1.56.1 is 
released. 

--8<---------------cut here---------------end--------------->8---

Is there a way for "guix lint" to check for the listed (other?)
"dangerous" codepoints and warn code reviewers?

Is it possible for the Guix community to start a coordinated effort to
analyze all the source code (ever?!?) published in out git repo to check
for the presence of this attack?

AFAIU there is not much Guix can do for the "Homoglyph attacks"
(CVE-2021-42694).

WDYT?

Happi hacking! Gio'


[1] https://www.openwall.com/lists/oss-security/2021/11/01/1

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

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

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

[Leo Famulari]

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.

What do others think?

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

[Bengt Richter]

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

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

[Ludovic Courtès]

Hi!

Giovanni Biscuolo <g@xelera.eu> skribis:

> The details are published here: https://www.trojansource.codes/

[...]

> Is there a way for "guix lint" to check for the listed (other?)
> "dangerous" codepoints and warn code reviewers?

That would be an expensive operation since that means unpacking the
source and reading each and every file.  ‘guix lint’ usually does
inexpensive checks.

> Is it possible for the Guix community to start a coordinated effort to
> analyze all the source code (ever?!?) published in out git repo to check
> for the presence of this attack?

That sounds unreasonable to me.

> AFAIU there is not much Guix can do for the "Homoglyph attacks"
> (CVE-2021-42694).

Right.  :-)

Guile itself could be “vulnerable” to this, though.  (I’m cautious about
terminology; for example, the ‘sayHello’ example on their web site uses
CYRILLIC CAPITAL LETTER EN vs. LATIN CAPITAL LETTER H.  Sure, their
glyphs are almost “visually indistinguishable”, but they belong to
different alphabets, and I’m wary of the implicit imperialist suggestion
that all things that roughly look like H should be replaced by H.)

Thanks,
Ludo’.

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

[zimoun]

Hi,

On Tue, 9 Nov 2021 at 18:10, Ludovic Courtès <ludo@gnu.org> wrote:
> Giovanni Biscuolo <g@xelera.eu> skribis:

> > Is there a way for "guix lint" to check for the listed (other?)
> > "dangerous" codepoints and warn code reviewers?
>
> That would be an expensive operation since that means unpacking the
> source and reading each and every file.  ‘guix lint’ usually does
> inexpensive checks.

I agree.  I miss what practical action could be done on the Guix side.
Somehow, we can clean and fix Guix code (and related source as Guile
or other strong direct dependencies) but the Guix project cannot fix
all the broken world of all source code of packages.

> > Is it possible for the Guix community to start a coordinated effort to
> > analyze all the source code (ever?!?) published in out git repo to check
> > for the presence of this attack?
>
> That sounds unreasonable to me.

It appears already unaffordable for only one Guix revision of 17k+
packages, so for all the source code (ever) published.  ;-)


Cheers,
simon

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

[Giovanni Biscuolo]

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

Hi!

Ludovic Courtès <ludo@gnu.org> writes:

> Giovanni Biscuolo <g@xelera.eu> skribis:
>
>> The details are published here: https://www.trojansource.codes/
>
> [...]
>
>> Is there a way for "guix lint" to check for the listed (other?)
>> "dangerous" codepoints and warn code reviewers?
>
> That would be an expensive operation since that means unpacking the
> source and reading each and every file.  ‘guix lint’ usually does
> inexpensive checks.

[...]

>> Is it possible for the Guix community to start a coordinated effort to
>> analyze all the source code (ever?!?) published in out git repo to check
>> for the presence of this attack?
>
> That sounds unreasonable to me.

OK, thanks all for your replies!

[...]

Ciao, Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

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