Re: "Trojan Source" (CVE-2021-42574 and CVE-2021-42694): can 'guix lint' help someway?
Hi! Ludovic Courtès writes: > Giovanni Biscuolo 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 signature.asc Description: PGP signature
Re: "Trojan Source" (CVE-2021-42574 and CVE-2021-42694): can 'guix lint' help someway?
Hi, On Tue, 9 Nov 2021 at 18:10, Ludovic Courtès wrote: > Giovanni Biscuolo 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?
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?
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?
"Trojan Source" (CVE-2021-42574 and CVE-2021-42694): can 'guix lint' help someway?
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 signature.asc Description: PGP signature
