https://thehackernews.com/2024/12/critical-openwrt-vulnerability-exposes.html
I am quite impressed that we have been living with this for almost half a month and we didn’t even know it before rest of the world?
3 Likes
Don't forget to shit yourself about a vuln which literally affected no one expected the dude who figured it out.
Srsly come on!
2 Likes
It wasn’t me that invented the show and made it global news…
The problem is that this forum is pretty much the OpenWrt PR department and this news (only the news headline it self) is bad PR for OpenWrt.
As is so frequently the case, @hnyman has published a definitive description of the situation, and what you should do about it (TL;DR - nothing, or not much. Read his note)
Sure, but you have blown into that horn, too...
What?! Oo
OpenWrt does not "need" nor has a "PR Department". And no, it's not bad news at all.
There was an issue someone could produce in a lab environment, not even on the production machine! The hole attack surface was rather hypothetical. And most impotently: The online service was power off immediately and a patch was installed not even 3 hours later...
If you wanna see bad "security" failures? Spend your time reading the news about all the million dollar companies like fortigate and avanti and all the others which this year delivered one hard fail after the other.
Just as an example from the last days: https://forums.ivanti.com/s/article/Security-Advisory-Ivanti-Cloud-Services-Application-CSA-CVE-2024-11639-CVE-2024-11772-CVE-2024-11773?language=en_US
- auth bypass for unauth user
- remote code insert and exec
- remote sql injection
This. is. bad. Because these are actually vuln which are running on the user/customer side AND are used to pwn ppl.
Edit ps: every user is also invited to let the image builder run locally on a PC.
Indeed, good point, it wasn't handled properly. It's mandatory to create a forum post, but for some reason it wasn't done in this case, sorry about that.
Well, this is not enough, it needs to be done officially in Release and security announcements section, like we've done previously Security Advisory 2022-10-17-1 - Multiple issues in mac80211 and cfg80211 (CVE-2022-41674, CVE-2022-42719, CVE-2022-42720, CVE-2022-42721 and CVE-2022-42722).
The procedure is hopefully more clear now https://openwrt.org/docs/guide-developer/security_incidents_response
1 Like
I did search the forum for ‘ASU’ as it was called in the actual report and on our own github repositories and not a single meaningful hit came up about this.
And if we look at the other “official” forum tread I wasn’t alone not finding any clues about this.
BTW I wouldn't personally downplay it, it was actually critical vulnerability, that service directly was serving daily about 1k firmware images to the users, so roughly 30k/month. That issue was there for about 5 months, which in worst case scenario makes it about 150k of possibly infected firmware deployments since 2024-07-08, when this flaw was introduced.
Indirectly it was possibly impacting quite a lot more users, because its known to be deployed as self-hosted by several other downstream projects.
2 Likes
But as far as I understood, the attacker had have to carefully craft images and the chance to hit someone by accident would be null and I would argue that some attacker would not use this vuln to specifically target a specific user.
Sure in Theory it's bad but from a practical side it is still rather an academic attack vector. And people just over hyped this issue far to much.
There were two vulnerabilities, the command injection is very serious, maybe you've just missed this attack vector?
It seams so? I have only the hash collisions on my horizon, so let me reread the announcement... 
Ok I have seen the cmd inject but I still find it rather irrelevant.
I just hope the image builder process is isolated somehow so system access is not that critical hopefully.
So it's rather a good entry point for the provoked hash collisions which are still a pretty advanced vector to spear fish a specific user.
@ynezz and just in case.l, I personally find that the issue and its handling was handled very good.
My impression stays that the hype and its wave were far to high. The response time was superb.
1 Like
Quoting the security researcher from Compromising OpenWrt Supply Chain via Truncated SHA-256 Collision and Command Injection
While the container that the command is executed in is isolated from the host, it’s still a good starting point to escape the container.
I agree with that. Container is basically just another process sharing the host kernel, so I consider it very low type of isolation.
But then again, I would assume in 2024 that the server is actually a VM where container for build jobs are started. So the barrier of escalation gets higher in higher. I would not say to swipe away the issue but for me it's more like pissing in the sea. In the end of the day there are far more serve issues out there and the risk for a user where probably pretty low on that one specifically.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.