Can the OP's link be changed to the original source, not the advertisement it currently links to? The exploit is documented https://blog.coffinsec.com/0day/2024/08/30/exploiting-CVE-20...
Not too surprising given what I've seen of their vendor sdk driver source code, compared to mt76. (Messy would be kind assessment)
Unfortunately, there are also some running aftermarket firmware builds with the vendor driver, due to it having an edge in throughput over mt76.
Mediatek and their WiSoC division luckily have a few engineers that are enthusiastic about engaging with the FOSS community, while also maintaining their own little OpenWrt fork running mt76.[1]
[1] https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk...
Why is it so much of this hardware/firmware feels so much like deploying a PoC to production? Why can't they hire someone that actually knows what they are doing?
Because you have to over pay all those executives and shareholders.
Hardware companies are bad at making software, and the corollary, software companies are bad at making hardware.
I feel like there's an opportunity for a joke here somewhere along the lines of hardware companies being really terrible at writing software, while software companies being just a normal amount of terrible at writing software.
In the middle you have Apple that is getting better at making certain kinds of hardware, worse at some hardware and definitely worse in software.
Because money
Is there any news releases or other information about that program, such as their goals, how much of the feed is merged upstream, etc?
I would like to remind people of the 2016 Adups backdoor:
> According to Kryptowire, Adups engineers would have been able to collect data such as SMS messages, call logs, contact lists, geo-location data, IMSI and IMEI identifiers, and would have been able to forcibly install other apps or execute root commands on all devices.
https://www.bleepingcomputer.com/news/security/android-adups...
The wappd service is primarily used to configure and coordinate the operations of wireless interfaces and access points using Hotspot 2.0 and related technologies. The structure of the application is a bit complex but it’s essentially composed of this network service, a set of local services which interact with the wireless interfaces on the device, and communication channels between the various components, using Unix domain sockets.
On the bright side, it doesn't sound like this is in baseband firmware but instead in a "value add" service that isn't 100% necessary to the functioning of the WNIC itself.
This reminds me of how some devices come with driver packages that include not just the actual driver software that's usually tiny and unobtrusive, but several orders of magnitude larger bloatware for features that 99% of users don't need nor want. Printers and GPUs are particularly guilty of this.
They say that OpenWrt 19.07 and 21.02 are affected, but as far as I can tell, official builds of OpenWrt only use the mt76 driver and not the Mediatek SDK.
It’s similar for Ubiquti:
https://community.ui.com/questions/CVE-2024-20017/b3f1a425-d...
There are vulnerable drivers for some chipsets used by UBNT hardware, but they have zero products that use those drivers.
I've been buying laptops with AMD CPU's but they always come with these trash MediaTek RZ616 Wi-Fi cards, why is that? I've been replacing them with Intel Wi-Fi cards, now I have a pile of RZ616 cards ready to become future microplastics :-(
You know why. Price.
IIRC my phone uses a MediaTek chipset. And I vaguely remember the vendor has moved away from MediaTek since because of the ahem quality of those products...
No idea how WiFi is done on a phone though. Is there a way to find out whether the phone is affected? I hardly ever use WiFi because I have unlimited cellular data and good coverage, but would still be good to know.
i still cannot fathom why in this day and age where people buy any silicon that's available, these C tier vendors don't adopt the PC strategy and completely open their firmwares for open source community.
FCC regulations around not making it easy to transmit outside of the licensed band tend to cause this.
Making the code available doesn’t necessarily mean that you can actually flash the image since it can be cryptographically locked down. Or even you support flashing but only let you do certain trusted operations from a signed image.
I feel like I'm missing something here.
Honestly, if you can't update the firmware you're in the same situation... knowing that you have a critical vulnerability and unable to fix it.
Enforcing trusted operations is definitely more work than they are going to do (if it's even possible to "do this right").
In a semi-ideal world, I would look for a vendor that permits only certain ops from a flashed image and hope that their crappy "restriction enforcing" code is also riddled with vulnerabilites so it's really just "follow the rules please".
Exploit is hard to distinguish between a back door here.
Posting claims of it being such is pretty easy, though.
There is a better middle ground here by saying the company that made it may not have known, but nation state threat actors most likely do.
When you see actors at this level set up manufacturing thousands of explosive filled devices at very high production quality, inserting some compromised things like printers or routers in a company network wouldn't be and shouldn't be a surprise.
If the nation state actors did intentionally backdoor it, then they would have wanted to make it look like incompetence. Here’s a link to the Simple Sabotage Field Manual from the US. It worked well in occupied Europe during WWII: