From: Skyler Ferris <skyvine@protonmail.com>
To: Andreas Enge <andreas@enge.fr>, Ekaitz Zarraga <ekaitz@elenq.tech>
Cc: "Ludovic Courtès" <ludo@gnu.org>,
"Attila Lendvai" <attila@lendvai.name>,
"Giovanni Biscuolo" <g@xelera.eu>,
"Guix Devel" <guix-devel@gnu.org>
Subject: Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)
Date: Sat, 13 Apr 2024 00:14:17 +0000 [thread overview]
Message-ID: <fac0c932-0dc6-4acf-b2d5-e82a3ffa66e6@protonmail.com> (raw)
In-Reply-To: <ZhfqfMcKgBSq6PDQ@jurong>
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
next prev parent reply other threads:[~2024-04-13 23:17 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-29 20:57 Backdoor in upstream xz-utils John Kehayias
2024-03-29 17:51 ` Ryan Prior
2024-03-29 20:39 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-03-29 20:55 ` Tomas Volf
2024-03-30 21:02 ` Ricardo Wurmus
2024-04-04 10:34 ` backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils) Giovanni Biscuolo
2024-04-04 15:12 ` Attila Lendvai
2024-04-04 16:47 ` Giovanni Biscuolo
2024-04-04 15:47 ` Giovanni Biscuolo
2024-04-04 19:48 ` Attila Lendvai
2024-04-04 20:32 ` Ekaitz Zarraga
2024-04-10 13:57 ` Ludovic Courtès
2024-04-11 12:43 ` Andreas Enge
2024-04-11 12:56 ` Ekaitz Zarraga
2024-04-11 13:49 ` Andreas Enge
2024-04-11 14:05 ` Ekaitz Zarraga
2024-04-13 0:14 ` Skyler Ferris [this message]
2024-04-19 14:31 ` Ludovic Courtès
2024-04-13 6:50 ` Giovanni Biscuolo
2024-04-13 10:26 ` Skyler Ferris
2024-04-13 12:47 ` Giovanni Biscuolo
2024-04-14 16:22 ` Skyler Ferris
2024-04-12 13:09 ` Attila Lendvai
2024-04-12 20:42 ` Ludovic Courtès
2024-04-13 6:13 ` Giovanni Biscuolo
2024-05-07 18:22 ` 3 kinds of bootstrap (was Re: backdoor injection via release tarballs combined with binary artifacts) Simon Tournier
2024-04-05 10:13 ` backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils) Giovanni Biscuolo
2024-04-05 14:51 ` Attila Lendvai
2024-04-13 7:42 ` Giovanni Biscuolo
2024-04-04 23:03 ` Ricardo Wurmus
2024-04-05 7:06 ` Giovanni Biscuolo
2024-04-05 7:39 ` Ricardo Wurmus
2024-04-05 16:52 ` Jan Wielkiewicz
2024-03-31 15:04 ` Backdoor in upstream xz-utils Rostislav Svoboda
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=fac0c932-0dc6-4acf-b2d5-e82a3ffa66e6@protonmail.com \
--to=skyvine@protonmail.com \
--cc=andreas@enge.fr \
--cc=attila@lendvai.name \
--cc=ekaitz@elenq.tech \
--cc=g@xelera.eu \
--cc=guix-devel@gnu.org \
--cc=ludo@gnu.org \
/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.