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]
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?
The wording of the headline is a bit misleading here. I followed the link thinking it might be a firmware or silicon bug as I have a couple of routers at home with mt76 wifi, but was relieved to find it's just a bug in the vendor's 'sdk' shovelware. I'm baffled that anyone even thought about using that, given there's such good mt76 support from mainline kernels with hostapd.
> I'm baffled that anyone even thought about using that, given there's such good mt76 support from mainline kernels with hostapd.
Not sure if you noticed but the OpenWRT 21.02.x series (based on mainline kernel 5.4 series) is affected, and these guys generally know their game when it comes to wireless on Linux. So much so that I think the mainline kernel mt76 driver is actually maintained by an OpenWRT developer.
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.
Is there some logic to MediaTek's naming conventions, or all their devices just MTxxxx where x is some incremented/random number?
I have a device with a mt6631 wifi chip and I'd assume it's unaffected just because it's not mentioned as affected anywhere, but it's hard to tell where it might fit into the lineup.
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.
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 :-(
Intel sells two versions of their WiFi cards: ones ending in 1 use CNVI protocol and work only with Intel chips. These are sold really cheap to OEMs; ones ending in 0 use standard PCIe and are sold to OEMs for ~$10 more.
AMD decided to brand Mediatek's MT7921 and MT7922 as RZ608 and RZ616 to have something to sell to OEMs at the same price point as Intel's xx1 chips.
Lenovo grew unhappy with MediaTek as well and started soldering down Qualcomm chips for WLAN on their AMD platforms only to be burned by buggy firmware/driver interactions on Linux (which they officially sell and support).
And Qualcomm stretches themselves rather thin on the mainline kernel side once a chipset generation is no longer the latest. It takes a tremendous amount of vendor pressure to make Qualcomm do anything these days.
iwlwifi has its own set of problems, biggest being no AP mode (on 5 Ghz). Also intels firmware license is more restrictive than mediateks, and being fullmac the firmware does lot more of the heavy lifting; I personally prefer softmac more. There simply aren't that many great options out there, gone are the golden days of ath9k.
Have you tried them further than "I don't trust MediaTek"?
I've had sequentially an Intel and an AMD ThinkPad for work (I killed the first one). Turns out, the wifi is much much better on the AMD one with the MediaTek chipset than on the Intel one with the Intel chipset. On the latter, I had very frequent disconnects from the network (severals per hour) along with atrocious latency even on 5GHz. And by atrocious latency, I mean atrocious as in "it is more than noticeable when using ssh". The current one has been rock solid for the past two or three years.
So yeah, I guess it really depends. The specific chipset I have is a MT7921 and I'm running Linux, YMMV. And it also may depend on the laptop itself.
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.
As a contributor to OpenWrt it makes me wonder why don't people differentiate between OpenWrt and various proprietary vendor SDKs. No one would have referenced Fedora if there was a bug in Nobara.
I don't think that link is necessarily better just because it's the original source. The linked article gives a concise overview, while the blog post spends the first paragraph talking about moving and starting a new job.
Their exploit development process is interesting, and I like to think I'd have done something similar (that is, compiling an easier-to-exploit version of the application and gradually working up to the real thing)
My anecdotal experience with mediatek wifi is it's a very flakey, low quality brand. That might be more of the reason. The firmware is probably unpolished, rushed, not maintained by competent people.
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.
Namidairo|1 year ago
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...
dylan604|1 year ago
molticrystal|1 year ago
qhwudbebd|1 year ago
Terretta|1 year ago
Vendors plural to worry about:
“…driver bundles used in products from various manufacturers, including [but not limited to] Ubiquiti, Xiaomi and Netgear.”
That said, vendors (plural) say no products use this, e.g. Ubiquiti:
https://community.ui.com/questions/CVE-2024-20017/b3f1a425-d...
vesinisa|1 year ago
Not sure if you noticed but the OpenWRT 21.02.x series (based on mainline kernel 5.4 series) is affected, and these guys generally know their game when it comes to wireless on Linux. So much so that I think the mainline kernel mt76 driver is actually maintained by an OpenWRT developer.
hunter-gatherer|1 year ago
userbinator|1 year ago
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.
Retr0id|1 year ago
I have a device with a mt6631 wifi chip and I'd assume it's unaffected just because it's not mentioned as affected anywhere, but it's hard to tell where it might fit into the lineup.
kam|1 year ago
hedora|1 year ago
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.
RedShift1|1 year ago
zekica|1 year ago
AMD decided to brand Mediatek's MT7921 and MT7922 as RZ608 and RZ616 to have something to sell to OEMs at the same price point as Intel's xx1 chips.
heffer|1 year ago
zokier|1 year ago
tuetuopay|1 year ago
I've had sequentially an Intel and an AMD ThinkPad for work (I killed the first one). Turns out, the wifi is much much better on the AMD one with the MediaTek chipset than on the Intel one with the Intel chipset. On the latter, I had very frequent disconnects from the network (severals per hour) along with atrocious latency even on 5GHz. And by atrocious latency, I mean atrocious as in "it is more than noticeable when using ssh". The current one has been rock solid for the past two or three years.
So yeah, I guess it really depends. The specific chipset I have is a MT7921 and I'm running Linux, YMMV. And it also may depend on the laptop itself.
0points|1 year ago
smilespray|1 year ago
usr1106|1 year ago
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.
tetris11|1 year ago
1oooqooq|1 year ago
userbinator|1 year ago
eqvinox|1 year ago
> The vulnerability resides in wappd, a network daemon included in the MediaTek MT7622/MT7915 SDK and RTxxxx SoftAP driver bundle.
OpenWRT doesn't seem to use wappd though?
zekica|1 year ago
caconym_|1 year ago
anthk|1 year ago
shadowpho|1 year ago
saagarjha|1 year ago
justmarc|1 year ago
mmsc|1 year ago
armada651|1 year ago
Retr0id|1 year ago
q3k|1 year ago
dang|1 year ago
https://news.ycombinator.com/newsguidelines.html
happosai|1 year ago
It is a broader ecosystem problem that there almost no incentive to write secure code. Security is an afterthought like documentation.
eqvinox|1 year ago
Can we stop with the snide comments now please? They're not helpful.
asveikau|1 year ago
anthk|1 year ago
unknown|1 year ago
[deleted]
cushychicken|1 year ago
[deleted]
BLACK_hHOLE2729|1 year ago
[deleted]
xtanx|1 year ago
> 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...
phh|1 year ago