Talos security vulnerabilities TALOS-2023-1844 / TALOS-2023-1845
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.
Signature · 5 lines
Bye, Peter Korsgaard _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Peter" == Peter Korsgaard <[email protected]> writes:
Hello,
Quoted 3 lines
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
Signature · 5 lines
Bye, Peter Korsgaard _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/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 <[email protected]>
Date: Mon, 11 Dec 2023 00:34:53 +0100
Subject: [PATCH 1/1] Add script w. generates custom version hash files
--- utils/generate-custom-version-hash-files.sh | 58 +++++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100755 utils/generate-custom-version-hash-files.sh
utils/generate- renamed from utils/generate-custom-version-hash-files.sh +0 -0
custom-version-hash-files.sh
new file mode 100755
index 0000000000..c5f10db616
utils/generate-custom-version-hash-files.sh new file +3 -0
@@ -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
Signature · 11 lines
2.25.1 _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Kilian" == Kilian Zinnecker <[email protected]> writes:
Hello,
Quoted 6 lines
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
Quoted 8 lines
uses a custom kernel, uboot, or ATF. If so, and if there exists a
BR2_GLOBAL_PATCH_DIRin 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).
Signature · 5 lines
Bye, Peter Korsgaard _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot