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

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

[Peter Korsgaard]

FYI,

Talos recently reported a number of security vulnerabilities in the
package download hash checking in Buildroot, and these are now public
at:

https://talosintelligence.com/vulnerability_reports/TALOS-2023-1844
https://talosintelligence.com/vulnerability_reports/TALOS-2023-1845

A small number of packages did not have a .hash file, meaning that the
downloaded sources were not verified - And for aufs + aufs-util they
were downloaded from a http:// site, so conceptually vulnerable to a man
in the middle attack.

aufs/aufs-utils were changed to fetch from https by:

https://gitlab.com/buildroot.org/buildroot/-/commit/f2a590750f5bedcee48ce7beb8f35356b42eda11
https://gitlab.com/buildroot.org/buildroot/-/commit/99d525028f969220719a4e6bcd694f7d9cfd5b67

The fallback download location on source.buildroot.net was changed to
use https:// by:

https://gitlab.com/buildroot.org/buildroot/-/commit/05296ced369bab8877efa624f3d9b4d201ba5b38

Hash files for riscv64-elf-toolchain and mxsldr were added by:

https://gitlab.com/buildroot.org/buildroot/-/commit/58d7c712d7d1ef5b439ead455a4ed2ca659b60fb
https://gitlab.com/buildroot.org/buildroot/-/commit/fefcfddc5e6a265c66adbdff615558f99133f148

Which are all included in 2023.02.7 / 2023.08.3 / 2023.11.


Some packages allow a custom version or even a custom upstream location
(E.G. Linux, U-Boot, versal-firmware, ..). For those custom versions
Buildroot naturally cannot provide the expected hash, so instead we have
added support for providing hashes for those files in the
BR2_GLOBAL_PATCH_DIR location and added a
BR2_DOWNLOAD_FORCE_CHECK_HASHES option to enforce hash checking (and
fail if missing/invalid) for all downloads. This was added by:

https://gitlab.com/buildroot.org/buildroot/-/commit/5d36710e36fc4698c8fae71675bcff7395246006
https://gitlab.com/buildroot.org/buildroot/-/commit/e091e31831122b60b084bd755e94df4dfe7188d2

To make it easier to manage these custom hash files a
utils/add-custom-hashes helper script has been added by:

https://gitlab.com/buildroot.org/buildroot/-/commit/4984d0f230d0962270beb195966603f1d5a56300

Which are all included in 2023.02.7 / 2023.08.3 / 2023.11.

See the documentation for further details about this feature:

https://buildroot.org/downloads/manual/manual.html#_adding_project_specific_patches_and_hashes

Notice that it is up to the user of Buildroot to use this feature to
protect their custom downloads!


Finally the toradex_apalis_imx6_defconfig fetched Linux and U-Boot from
a git:// URL, so custom hashes were added in the BR2_GLOBAL_PATCH_DIR
for those by:

https://gitlab.com/buildroot.org/buildroot/-/commit/cdc9b8a3a75c4c39f23feb4e3b0e296786e0132c

Which is included in 2023.02.8 / 2023.08.4 / 2023.11.


Thanks to Talos for discovering and reporting these issues to us and to
Yann E. MORIN for implementing the custom hash logic.

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

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

[Peter Korsgaard]

>>>>> "Peter" == Peter Korsgaard <peter@korsgaard.com> writes:

Hello,

 > Hash files for riscv64-elf-toolchain and mxsldr were added by:

 > https://gitlab.com/buildroot.org/buildroot/-/commit/58d7c712d7d1ef5b439ead455a4ed2ca659b60fb

Sorry, wrong commit. The correct one is:

https://gitlab.com/buildroot.org/buildroot/-/commit/cf2dcaa1ecede670a0bc54841652a0e3bea5c744

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

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

[Kilian Zinnecker via buildroot]

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.)

------

From af10775dbee7d8e785cb71e4492a89f1412fe997 Mon Sep 17 00:00:00 2001
From: Kilian Zinnecker <kilian.zinnecker@mail.de>
Date: Mon, 11 Dec 2023 00:34:53 +0100
Subject: [PATCH 1/1] Add script w. generates custom version hash files

Signed-off-by: Kilian Zinnecker <kilian.zinnecker@mail.de>
---
 utils/generate-custom-version-hash-files.sh | 58 +++++++++++++++++++++
 1 file changed, 58 insertions(+)
 create mode 100755 utils/generate-custom-version-hash-files.sh

diff --git a/utils/generate-custom-version-hash-files.sh b/utils/generate-
custom-version-hash-files.sh
new file mode 100755
index 0000000000..c5f10db616
--- /dev/null
+++ b/utils/generate-custom-version-hash-files.sh
@@ -0,0 +1,58 @@
+#!/bin/bash
+
+# This script checks all defconfigs for custom kernel, u-boot and ATF and 
tries
+# to add a hash file into the BR2_GLOBAL_PATCH_DIR, if it is set.
+
+configs_dir=./configs
+
+if [ -z ${1+x} ]
+then
+    defconfig_start="!"
+else
+    defconfig_start=$1
+fi
+
+cd ..
+
+for defconfig_path in "$configs_dir"/*
+do
+    if [[ "$defconfig_path" != *_defconfig ]]
+    then
+        continue
+    fi
+
+    defconfig_filename="$(basename -- $defconfig_path)"
+    defconfig_name=${defconfig_filename%_*}
+
+    if [ $defconfig_filename \< $defconfig_start ]
+    then
+        continue
+    fi
+
+    if ! grep -Eq "^BR2_LINUX_KERNEL_CUSTOM_VERSION=y*$|
^BR2_LINUX_KERNEL_CUSTOM_TARBALL=y*$|^BR2_TARGET_UBOOT_CUSTOM_VERSION=y*$|
^BR2_TARGET_UBOOT_CUSTOM_TARBALL=y*$|
^BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_VERSION=y*$|
^BR2_TARGET_AT91BOOTSTRAP3_CUSTOM_TARBALL=y" \
+        $defconfig_path
+    then
+        echo $defconfig_name > last_defconfig
+        continue
+    fi
+
+    if ! grep -Eq "^BR2_GLOBAL_PATCH_DIR" $defconfig_path
+    then
+        echo $defconfig_name >> unhandled_defconfigs
+        echo $defconfig_name > last_defconfig
+        continue
+    fi
+
+    if ! grep -Exq "^BR2_DOWNLOAD_FORCE_CHECK_HASHES=y" $defconfig_path
+    then
+        echo "BR2_DOWNLOAD_FORCE_CHECK_HASHES=y" >> $defconfig_path
+    fi
+
+    make clean
+    make $defconfig_filename
+    ./utils/add-custom-hashes
+
+    echo $defconfig_name >> handled_defconfigs
+    echo $defconfig_name > last_defconfig
+
+done
-- 
2.25.1






_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Peter Korsgaard]

>>>>> "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