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...
In an ideal world, consumers would be happy to pay a premium for a device that's a generation behind in terms of features but has really good firmware. In the real world, only Apple have the kind of brand and market power to even attempt that.
This seems like the exact place where open source is a competitive advantage.
Step 1, open source your existing firmware for the previous generation hardware. The people who have the hardware now fix problems you didn't have the resources to fix.
Step 2, fork the public firmware for the previous generation hardware when developing the next generation. It has those bug fixes in it and 90% of the code is going to be the same anyway. Publish the new source code on the day the hardware ships in volume but not before. By then it doesn't matter if competitors can see it because "designs become obsolete very quickly" and it's too late for them to use it for their hardware/firmware in this generation. They don't get to see your next generation code until that generation is already shipping. Firmware tricks that span generations and have significant value can't be kept secret anyway because any significant firmware-based advantage would be reverse engineered by competitors for the next generation regardless of whether they have the source code.
Now your development costs are lower than competitors' because you didn't have to pay to fix any bugs that one of your customers fixed first, and more people buy your hardware because your firmware is less broken than the competition.
On top of that, there's bound to be errors in the hardware design, no modern technology even comes close to being formally proven correct, it's just too damn complex/large. Only after the first tapeout of an ASIC you can actually test it and determine what you need to correct and where to correct it (microcode, EC firmware, OS or application layer).
Because those employees cost a lot of money and these commodity widgets have razor thin margins that don't enable them to pay high salaries while also making enough profit to stay in business.
You can pay more to hire better people and put the extra cost in the price of the product but then HP, Lenovo, Dell, et-al aren't gonna buy your product anymore, they're gonna buy instead from your competition who's maybe worse but provides lower prices which is what's most important for them because the average end user of the laptop won't notice the difference between network cards but they do check the sticker price of the machine on Amazon/Walmart and make the purchasing decision on that and stuff like the CPU and GPU not on the network card in the spec sheet.
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...
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.
https://openwrt.org/advisory/start
Maybe MediaTek has shipped some modified versions of OpenWRT using this "wappd" thing to their B2B customers (as part of the SDK perhaps?) and are now advertising those as vulnerable.
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.
I've done some Android development so let me translate that for you: "layers upon layers of dog shit APIs"
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.
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.
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.
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.
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.
ls /sys/module
https://news.ycombinator.com/item?id=23341711
Today it's giving way to "useless use of su" where admins aren't aware of sudo(8) options like "-s" or "-i"
The termux developers, knowing this, set it such that the default termix user can invoke sudo without a password.
It might seem lazy, but its very useful
No matter what the software says, or what keys it has set, the hardware should still be hard-configured to honour regional power output limits. This could be something like a block of DIP switches under the cover, so if a user unbolts the case, finds the switch, and toggles it to some country with looser requirements, it's obviously going against manufacturer advice and washes their hands of liability.
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".
going the pc route is fully embracing your hardware accept whatever software the user wants. not throw unbuildable source somewhere and make it impossible to use. that's the faux open source we have today when someone must comply with the gpl or something
(no, a PLL is not considered a "hardware oscillator" in any practical sense by anyone working in this area, that's "tomatoes in a fruit salad" category)
> 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?
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.
It is a broader ecosystem problem that there almost no incentive to write secure code. Security is an afterthought like documentation.
Really? I think an extraordinary claim like "eliminating a whole class of problems makes applications no more secure in general" should also come with extraordinary evidence.
Can we stop with the snide comments now please? They're not helpful.
> 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...