* [Buildroot] Talos security vulnerabilities TALOS-2023-1844 / TALOS-2023-1845 @ 2023-12-06 8:15 Peter Korsgaard 2023-12-10 22:51 ` Peter Korsgaard 0 siblings, 1 reply; 4+ messages in thread From: Peter Korsgaard @ 2023-12-06 8:15 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Buildroot] Talos security vulnerabilities TALOS-2023-1844 / TALOS-2023-1845 2023-12-06 8:15 [Buildroot] Talos security vulnerabilities TALOS-2023-1844 / TALOS-2023-1845 Peter Korsgaard @ 2023-12-10 22:51 ` Peter Korsgaard 2023-12-10 23:53 ` Kilian Zinnecker via buildroot 0 siblings, 1 reply; 4+ messages in thread From: Peter Korsgaard @ 2023-12-10 22:51 UTC (permalink / raw) To: buildroot >>>>> "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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Buildroot] Talos security vulnerabilities TALOS-2023-1844 / TALOS-2023-1845 2023-12-10 22:51 ` Peter Korsgaard @ 2023-12-10 23:53 ` Kilian Zinnecker via buildroot 2023-12-11 8:43 ` Peter Korsgaard 0 siblings, 1 reply; 4+ messages in thread From: Kilian Zinnecker via buildroot @ 2023-12-10 23:53 UTC (permalink / raw) To: 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 ^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [Buildroot] Talos security vulnerabilities TALOS-2023-1844 / TALOS-2023-1845 2023-12-10 23:53 ` Kilian Zinnecker via buildroot @ 2023-12-11 8:43 ` Peter Korsgaard 0 siblings, 0 replies; 4+ messages in thread From: Peter Korsgaard @ 2023-12-11 8:43 UTC (permalink / raw) To: Kilian Zinnecker; +Cc: buildroot >>>>> "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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-12-11 8:43 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-12-06 8:15 [Buildroot] Talos security vulnerabilities TALOS-2023-1844 / TALOS-2023-1845 Peter Korsgaard 2023-12-10 22:51 ` Peter Korsgaard 2023-12-10 23:53 ` Kilian Zinnecker via buildroot 2023-12-11 8:43 ` Peter Korsgaard
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox