A security issue that could have allowed attackers to serve malicious firmware images to users has been fixed by OpenWrt Project, the organization that helms the development of the popular Linux distribution for embedded devices.
About OpenWrt
OpenWrt is a customizable operating system that’s primarily used for wireless home routers by various manufacturers, instead of the OS/firmware provided by them.
“Instead of trying to create a single, static firmware, OpenWrt provides a fully writable filesystem with optional package management,” the project boasts.
“For developers, OpenWrt provides a framework to build an application without having to create a complete firmware image and distribution around it. For users, this means the freedom of full customization, allowing the use of an embedded device in ways the vendor never envisioned.”
The OpenWrt security issue
The security issue has been found in OpenWrt’s Attendedsysupgrade Server (ASU), an image-on-demand server for OpenWrt-based distributions.
The server powers the service (sysupgrade.openwrt.org) that allows users to request a new firmware image with their specific device and desired software packages in mind. Once the image is created and delivered, OpenWrt (the OS on the device) implements it.
The issue consists of two vulnerabilities:
- A command injection in Imagebuilder, which may allow malicious users to inject arbitrary commands into the firmware build process (and create malicious firmware images signed with the legitimate build key)
- A SHA-256 hash collision issue (CVE-2024-54143): A hash of the request for building a firmware image is created, but unfortunately the server truncates it to the first 12 characters (out of 64), which may allow attackers to generate collisions.
“By exploiting [the hash collision issue], a previously built malicious image can be served in place of a legitimate one, allowing the attacker to ‘poison’ the artifact cache and deliver compromised images to unsuspecting users,” OpenWrt developer Paul Spooren explained in an email sent to the project’s mailing list.
Security researcher Ry0taK (of Flatt Security), who found and privately disclosed the issue to the OpenWrt developers, demonstrated how combining these two issues may allow attackers to replace benign firmware images with a previously built malicious ones.
What should you do?
OpenWrt’s Spooren confirmed that:
- The issue affected all ASU instances including the the official instance (sysupgrade.openwrt.org), which “runs on dedicated servers separate from OpenWrt Buildbot and doesn’t have access to any sensible resource (SSH Keys, Sign Certs…)”
- None of the official images hosted on downloads.openwrt.org nor custom images from 24.10.0-rc2 were affected
“Available build logs for other custom images were checked and NO MALICIOUS REQUEST FOUND, however due to automatic cleanups no builds older than 7 days could be checked,” he added.
“Although the possibility of compromised images is near 0, it is SUGGESTED to the user to make an INPLACE UPGRADE to the same version to ELIMINATE any possibility of being affected by this.”
Users who run a public, self-hosted instance of ASU are advised to update it immediately or apply two outlined commits.