top | item 41605680

Critical Exploit in MediaTek Wi-Fi Chipsets: Zero-Click Vulnerability

259 points| pjf | 1 year ago |blog.coffinsec.com

103 comments

order

Namidairo|1 year ago

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...

dylan604|1 year ago

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?

molticrystal|1 year ago

Is there any news releases or other information about that program, such as their goals, how much of the feed is merged upstream, etc?

qhwudbebd|1 year ago

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.

Terretta|1 year ago

> relieved to find it's just a bug in the vendor's 'sdk' shovelware

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

> 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.

hunter-gatherer|1 year ago

userbinator|1 year ago

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.

Retr0id|1 year ago

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.

kam|1 year ago

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.

RedShift1|1 year ago

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 :-(

zekica|1 year ago

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.

heffer|1 year ago

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.

zokier|1 year ago

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.

tuetuopay|1 year ago

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.

0points|1 year ago

You get what you pay for.

usr1106|1 year ago

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.

tetris11|1 year ago

termux -> "sudo su" and then

    ls /sys/module
(it gives an output similar to lsmod)

1oooqooq|1 year ago

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.

userbinator|1 year ago

FCC regulations around not making it easy to transmit outside of the licensed band tend to cause this.

eqvinox|1 year ago

> The affected versions include MediaTek SDK versions 7.4.0.1 and earlier, as well as OpenWrt 19.07 and 21.02.

> 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

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.

caconym_|1 year ago

Came here wondering this, as I have several Netgear APs running OpenWRT on my home network. Sounds like I'm in the clear?

anthk|1 year ago

That's why we need free firmware. I'm tired of Broadcom and Ralink.

shadowpho|1 year ago

Exploit is hard to distinguish between a back door here.

saagarjha|1 year ago

Posting claims of it being such is pretty easy, though.

justmarc|1 year ago

Welcome back to the 90s.

mmsc|1 year ago

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...

armada651|1 year ago

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.

Retr0id|1 year ago

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)

q3k|1 year ago

[flagged]

happosai|1 year ago

Well it was solved decades ago in Java yet Java apps have proven no more secure in general.

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

C, C++ and assembly are 3 languages where this regularly happens.

Can we stop with the snide comments now please? They're not helpful.

asveikau|1 year ago

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.

anthk|1 year ago

Not an issue with ath9k. Guess why. Hint: not Rust related.

xtanx|1 year ago

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...

phh|1 year ago

How is this relevant?