Re: [Buildroot] Talos security vulnerabilities TALOS-2023-1844 / TALOS-2023-1845

From: Peter Korsgaard <peter@korsgaard.com>
To: Kilian Zinnecker <kilian.zinnecker@mail.de>
Cc: buildroot@buildroot.org
Subject: Re: [Buildroot] Talos security vulnerabilities TALOS-2023-1844 / TALOS-2023-1845
Date: Mon, 11 Dec 2023 09:43:50 +0100	[thread overview]
Message-ID: <874jgpnn7d.fsf@48ers.dk> (raw)
In-Reply-To: <12337986.O9o76ZdvQC@kilian-aisec> (Kilian Zinnecker's message of "Mon, 11 Dec 2023 00:53:11 +0100")

>>>>> "Kilian" == Kilian Zinnecker <kilian.zinnecker@mail.de> writes:

Hello,

 > Hello Peter, all,
 > as far as I see it, most package within buildroot have hash files. So, would it
 > make sense, that we use the new feature and actually add hash files, if a board
 > uses a custom versions of the kernel, uboot, etc.? If so, it would not be very
 > convenient to add all the hash files manually. I started writing a script,
 > which goes through all defconfigs an tries to identify, whether the defconfig
 > uses a custom kernel, uboot, or ATF. If so, and if there exists a
 > BR2_GLOBAL_PATCH_DIR in the defconfig, the script runs your "add-custom-hashes"
 > script, which then adds the hash files. My script is far from perfect. But I
 > wanted to ask for an opinion, before I continue putting more effort into it.
 > Running the script for all defconfigs would take quite some time and probably
 > use a huge amount of disk space. See a patch containing the script below. (I
 > don't advocate for really adding the script to buildroot, the patch is just a
 > way to share the script.)

It is all a question about our threat model. The hashes protect against
getting different sources than we were expecting, but adding hashes for
custom package versions also brings some overhead.

As I see it, we basically have:

Downloads from a non-HTTPS/non-TLS location: Vulnerable to man in the
middle attacks, we should add a .hash to protect against that,
E.G. see commit cdc9b8a3a75c4c

For downloads from a HTTPS/TLS location we don't have a (realistic)
man-in-middle risk, but the server owner could change the file. We
should add a hash to protect against that / be able to detect that,
E.G. see commit cf2dcaa1ecede

Among the HTTPS/TLS downloads, a (big) subset of those refer to git
hashes, meaning that the site owner cannot (realisticly) change the
content of the files. I would argue that the risk is so low that it is
not worth the extra overhead to add hashes for those.

I believe this is the situation today in Buildroot, so if we agree on
that threat model / these mitigations then there is nothing more to do
(unless something slipped through the cracks).

-- 
Bye, Peter Korsgaard
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot