Six vulnerabilities were detected in Buildroot that allows remote code execution

vulnerability

If exploited, these flaws can allow attackers to gain unauthorized access to sensitive information or generally cause problems

Recently Cisco Talos (the cybersecurity research and development division of Cisco Systems) made it known, through a blog post, information about the discovery of a number of vulnerabilities in the Buildroot build system.

Cisco Talos I mention the discovery of six vulnerabilities in Buildroot that allow, during interception of transit traffic (MITM), make changes to generated system images or arrange code execution in the build system.

The first five vulnerabilities cataloged under TALOS-2023-1844 (CVE-2023-45841, CVE-2023-45842, CVE-2023-45838, CVE-2023-45839, CVE-2023-45840) affect the code to verify the integrity of packets using hashes.

Problems They boil down to the ability to use HTTP to download files and the lack of file verification hashes for some packets, allowing the content of these packets to be replaced, having the opportunity to interfere with the build server's traffic (for example when a user connects through a wireless network controlled by an attacker).

Because packages can include patch files or Makefiles, by providing a compromised source package, an attacker could execute arbitrary commands in the compiler. As a direct consequence, an attacker could also alter any files generated for Buildroot targets and hosts.

In particular, the aufs and aufs-util packages were loaded over HTTP and were not compared with hashes. Also missing hashes for the riscv64-elf-toolchain, versal-firmware, and mxsldr packages, which were loaded over HTTPS by default, but fell back to unencrypted downloads in case of problems. If there were no ".hash" files, the Buildroot tool considered the verification successful and processed the downloaded packages, including applying any patches included in the packages and running build scripts.

By having the ability to spoof downloaded packages, the attacker could add his own patches or Makefiles to them, allowing changes to be made to the resulting image or creating system scripts and having their code executed.

On the part of the sixth vulnerability which was classified under TALOS-2023-1845 (CVE-2023-43608) is caused by an error in the implementation of the functionality BR_NO_CHECK_HASH_FOR, which allows you to disable the checks hash integrity for selected packets.

It is mentioned that to:

Each hash line in the .hash file is called check_one_hash. If hash does not match, check_one_hash will exit with an error code. Otherwise, nb_checks is incremented to indicate a successful check. If there is no entry in the .hash file to check the specified input file, the check in the IF condition will return an error unless BR_NO_CHECK_HASH_FOR[9] contains this specific file, which means the file is excluded from the checks of hash.

In total, There are 3 ways to check-hash returns the value 0:

  1. .hash no file exists for package
  2. $file hash matches the definition of the .hash file
  3. $file is not present in the .hash file and BR_NO_CHECK_HASH_FOR contains the base name of the package (explicitly bypassing the checks)

For the concept of vulnerability demonstration, developers focused on option 3, as this seems to be commonly used to bypass integrity checks for resources that cannot be easily hashed (e.g. development resources that change frequently). It is also used when creating specific versions of a package, for which hashes may not be available in the Buildroot sources.

Some packages, such as the Linux kernel, U-Boot, and versal-firmware, allowed loading the latest versions for which verification hashes had not yet been generated. For these versions the BR_NO_CHECK_HASH_FOR option was used, which disables hash verification.

Data was downloaded over HTTPS, but by default, if the download failed, an alternative was used to access the site without encryption using the http:// protocol. During a MITM attack, an attacker could block the connection to the HTTPS server and then the download is rolled back.

Finally, it should be mentioned that vulnerabilities are resolved in latest Buildroot versions and if you are interested in being able to know more about it, you can consult the details In the following link.


Leave a Comment

Your email address will not be published. Required fields are marked with *

*

*

  1. Responsible for the data: Miguel Ángel Gatón
  2. Purpose of the data: Control SPAM, comment management.
  3. Legitimation: Your consent
  4. Communication of the data: The data will not be communicated to third parties except by legal obligation.
  5. Data storage: Database hosted by Occentus Networks (EU)
  6. Rights: At any time you can limit, recover and delete your information.