Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)

[Skyler Ferris]

Hi all,

On 4/11/24 06:49, Andreas Enge wrote:
> Am Thu, Apr 11, 2024 at 02:56:24PM +0200 schrieb Ekaitz Zarraga:
>> I think it's just better to
>> obtain the exact same code that is easy to find
> The exact same code as what? Actually I often wonder when looking for
> a project and end up with a Github repository how I could distinguish
> the "original" from its clones in a VCS. With the signature by the
> known (this may also be a wrong assumption, admittedly) maintainer
> there is at least some form of assurance of origin.

I think this assumption deserves a lot more scrutiny than it typically 
gets (this is a general statement not particular to your message; even 
the tails project gets this part of security wrong and they are 
generally diligent in their efforts). I find it difficult to download 
PGP keys with any degree of confidence. Often, I see a file with a 
signature and a key served by the same web page, all coming from the 
same server. PGP keys are only useful if the attacker compromised the 
information that the user is receiving from the web page (for example, 
by gaining control of the web server or compromising the HTTPS session). 
In the typical scenario I have encountered, the attacker would also 
replace the key and signature with ones that they generated themself.

In short, I'm not sure that we actually get any value from checking the 
PGP signature for most projects. Either HTTPS is good enough or the 
attacker won. 99% of the time HTTPS is good enough (though it is notable 
that the remaining 1% has a disproportionate impact on the affected 
population).

Some caveats:

It's difficult for me to use web of trust effectively because I haven't 
met anyone who uses PGP keys IRL. I'm ultimately trusting my internet 
connection and servers which are either semi-centralized (there are not 
that many open keyservers, it's an oligopoly for lack of a better term) 
or have the problem described above. So maybe everyone else is using web 
of trust effectively and I don't know what I'm talking about. =)

The key download could be compared to the "trust on first use" model 
that SSH uses. It's not clear to me how effective a simple text box 
saying "we rotated our keys so you need to re-download it!" would be, 
but I suspect that most people would download without a second thought. 
It might be interesting to add public keys and signature locations to 
package definitions and have Guix re-verify the signature when it 
downloads the source. This would provide more scrutiny when keys are 
rotated (because of the review process) and would prevent harm from the 
situation where the package author is re-downloading the key each time 
the software is updated.

The review process also adds a significant layer of protection because 
an attacker would need to compromise the HTTPS session of the reviewer 
in addition to the original package author (assuming that the signature 
is re-checked by the reviewer; I'm not sure how often this happens in 
practice). In principle it should be difficult for an attacker to 
predict who will be reviewing which issue. However, if the pool of 
reviewers is small it would be easier for the attacker to predict this 
or just compromise all of the reviewers. Also, if there was some way for 
the attacker to launch a general attack on people working out of the 
Guix repository then the value of this protection becomes negligible.

The above two paragraphs are somewhat at odds: if Guix has the public 
key baked in and knows where to download the signature, some reviewers 
might not double-check the key that they get from the website because 
Guix is doing it for them. On one hand, I generally think that 
automating security makes it worse because once it's automated there's a 
system of rules for attackers to manipulate. On the other hand, if we 
assume people aren't doing the things they need to then no amount of 
technical support will give us a secure system. How much is reasonable 
to expect of people? From my extremely biased perspective, it's 
difficult to say.

>> and everybody is reading.
> This is a steep claim! I agree that nobody reads generated files in
> a release tarball, but I am not sure how many other files are actually
> read.
>
> Andreas

I would guess that the level of the protection is strongly correlated 
with the popularity of the project among developers who need to add 
features or fix bugs. I don't think anybody reads a source repository 
"cover to cover", but we rummage around in the code on an as-needed 
basis. It would probably be difficult to sneak something into core 
projects like glibc or gcc, but pretty easy to sneak something into 
"emojis-but-cooler.js". It would be better to have comprehensive audits 
of all the projects, but that's not something Guix can manage by itself. 
It could make it easier to free up resources for that task, but I digress.

While it is hyperbolic to say that "with enough eyes, all bugs are 
shallow" there is a kernel of truth to it. There's a reason they hid the 
noticeably malicious macros in the release tarball.

In solidarity,
Skyler