Open source router firmware project fixes dusty old  code.

ASU 48-bit Trash Hash

What’s the craic? Michael Larabel reports: OpenWrt Affected By Security Issue

“Possibility of being affected”
A security issue was reported to the OpenWrt project this week around their Attendedsysupgrade Server (ASU) instances that could have led to compromised firmware images. … It’s believed no official images from downloads.openwrt.org were affected.
…
OpenWrt developers were only able to verify the build logs for the past seven days. … Users [should do] in-place upgrades to the same version to eliminate any possibility of being affected.

OpenWhatnow? Bill Toulas explains: OpenWrt Sysupgrade flaw let hackers push malicious firmware images

“Everyone should take the recommended action”
OpenWrt is a highly customizable, open-source, Linux-based operating system designed for embedded devices, particularly network devices like routers, access points, and other IoT hardware. The project is a popular alternative to a manufacturer’s firmware as it offers numerous advanced features and supports routers from ASUS, Belkin, Buffalo, D-Link, Zyxel, and many more.
…
A flaw in OpenWrt’s Attended Sysupgrade feature used to build custom, on-demand firmware images could have allowed for the distribution of malicious firmware packages. … The critical (CVSS v4 score: 9.3) flaw, tracked as CVE-2024-54143, was fixed within hours of being disclosed to OpenWrt’s developers.
…
The team says it’s highly unlikely that anyone has exploited [it] and they have found no evidence that this vulnerability impacted images from downloads.openwrt.org. However, … this issue has existed for a while, so there are no cut-off dates, and everyone should take the recommended action out of an abundance of caution.

What should people do? Let’s ask OpenWrt’s Paul Spooren: Attended Sysupgrade Server CVE-2024-54143

“Update it immediately”
Impact: An attacker can compromise the build artifact delivered from the sysupgrade.openwrt.org, allowing the malicious firmware image to be installed. … Thanks to RyotaK from Flatt Security Inc. for finding and reporting this issue.
…
Although the possibility of compromised images is near 0, it is suggested to the user to make an in-place upgrade to the same version to eliminate any possibility of being affected by this. If you run a public, self hosted instance of ASU, please update it immediately.

Horse’s mouth? It’s a big 今日は to RyotaK:

A few days ago, I was upgrading my home lab network, and I decided to upgrade the OpenWrt on my router. After accessing … the web interface of OpenWrt, I noticed that there is a section called Attended Sysupgrade, so I tried to upgrade the firmware using it. … I was curious about how it works, so I decided to investigate.
…
When the user tries to upgrade the firmware, OpenWrt … sends a request to the server with the required information. … The server then builds the firmware image based on the information and sends it back to the OpenWrt, which then flashes the firmware image. … If the server is building the user-provided source code and is not properly isolated, it can be easily compromised.
…
I … noticed that the length of the hash is truncated to 12, out of 64 characters. 12 characters are equivalent to 48 bits … , which seems to be too small to avoid collisions. … by creating a collision of the packages’ hash, we can produce the same cache key even if the packages are different. This allows an attacker to force the server to return the wrong build artifact for requests that have different packages.

Why on Earth would they do that? iforgotpassword suggestifies thuswise:

Truncated hash functions are not vulnerable to length-extension attacks. But you usually take SHA512 and truncate to 256 bits. Anything shorter than this isn’t really considered safe these days.

Yes, well, 48 is definitely shorter than 256. Dan 55 can’t quite believe his eyes:

What? How? Perhaps nobody widened the field since the days when they were using CRC?

Dangerous build system is dangerous. ssokolow would like to see the Python code rewritten in Rust:

As a Python programmer moving things to Rust, I have to say … Python has just about the weakest type system you can get. … Rust can reduce bad coding that has nothing to do with memory safety in two ways:
— Reducing the mental burden on people auditing PRs so problems like that are more noticeable,
— Dependencies exposing APIs that are harder to “hold wrong.”

Impressively fast turnaround, though. Looking back to last month’s D-Link story, micw sounds slightly sarcastic:

That’s why open source can never compete with business grade closed source stuff:
— They fixed it in 3 hours instead of making customers wait 6 months for a patch (if any),
— They did not try to sue the reporter of the issue,
— They did not even tell the users to throw away the “outdated” but perfectly working devices.

Meanwhile, a few people seemed to miss micw’s humorous tone. Yet Another Anonymous coward rolls their eyes:

That’s the trouble with open source: Everyone is responsible for writing their own jokes.

And Finally:

Just when you think this can’t get more bizarre … it does

Hat tip: jonbob

Previously in And Finally

You have been reading SB Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites—so you don’t have to. Hate mail may be directed to  @RiCHi, @richij, @[email protected], @richi.bsky.social or [email protected]. Ask your doctor before reading. Your mileage may vary. Past performance is no guarantee of future results. Do not stare into laser with remaining eye. E&OE. 30.

Image sauce: FreeWear.org