Critical Exploit in MediaTek Wi-Fi Chipsets: Zero-Click Vulnerability(blog.coffinsec.com) |
Critical Exploit in MediaTek Wi-Fi Chipsets: Zero-Click Vulnerability(blog.coffinsec.com) |
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.
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.
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"
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.
> 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...
(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)
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.
The OpenWrt folks generally have good enough taste not to ship any drivers or userspace junk from vendor SDKs, though they do have a fair-sized set of backport patches on top of the (somewhat elderly) mainline kernels they do ship.
I'm running up-to-date mainline on my routers, not OpenWrt kernels. The mt76 support in 6.11 (and previously in 6.9 and 6.10) is complete enough that I don't need to carry any patches at all over what's in Linus' tree.
I definitely agree with the guideline around favoring original sources, but this seems like a good time to deviate.
The number of CVEs reveals that there is a lot of Java software and that there's a strong culture of importing dependencies. But we also care about the nature of them, the normalized relative frequency of very serious flaws like RCE exploits.
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
I think it's also rich calling GPL compliance faux open source. There really is no true Scotsman.
Thank you.
Manufacturers of radios have to prevent the ability to behave in a non-compliant manner. One way of accomplishing that is preventing the user from updating software to non-official versions. Another is to prevent the small subset of functionality to be updated by non-official versions. This isn't a new requirement and has been around since forever.
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.
Note that I'm still pro-open source, but I've seen this cycle play out in the real world enough times to understand why manufacturers are paranoid about releasing anything that might help a competitor, even if it benefits their customers.
The entire premise of firmware is that it's specific to the hardware. By the time they "copy your hardware" it's already obsolete. Also, that's the thing you're actually selling. Your firmware sucks. Nobody wants your firmware unless they have your hardware. People are paying you for the hardware, which is the thing cheap competitors can't make as well as you or you're already screwed.
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).
Inertia is a hell of a thing, but you are starting to see the cracks form. I just don’t know if there is an alternative.
I'm talking things like full OS crashes while doing absolutely nothing, no traffic whatsoever or even better, silently starting to drop all network traffic (relatively silently, just an error message in the logs, but otherwise no indication, the interface still shows up as fine and up in the OS). It was all a driver issue (although both Intel drivers didn't work, so not only) that was later fixed.
After that, it was rock solid. But the fact that there was a high class network card sold for lots of money, on hardware compatibility lists at various vendors, which didn't work at all for pretty much everyone for more than a few years is disgusting.
[0] - That came up once.
"sync<CR>sync<CR>sync<CR>reboot<CR>" became an idiom for various reasons. Then it became "sync; sync; sync; reboot" and deemed equivalent, which was missing the point that physically pressing "enter" introduced some human-length pauses into the process. Then "reboot(8)" incorporated those syncs, and "shutdown(8)" provided more flexibility, but the idiom persisted.
And to this day, the tier-1 support script says to clear your cookies and cache, try a different browser, factory reset your phone, disable firewall, disable AV, reboot your router, bypass your switch and plug in one device directly, wait 15 minutes and try again, and we've abandoned all attempts to understand, diagnose, or find root causes when the underlying systems are too diverse and complex to understand or keep your tech's expertise up-to-date.
So maybe Perl is not so write-only after all ? ;)
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
People writing "sudo su" are simply imitating a common StackExchange idiom without knowing why.
"su" requires passwords unless invoked by root. "sudo" may be configured to permit/deny specific commands. So if you write that, then you're saying 'become root via the sudoers(5) config and then fork, exec, become root again via the setuid binary "su", in order to run an interactive shell.'
It's a poor habit to be promoting, because it assumes things about the configuration and suggests that "su" is equal to other particular "sudo" maintenance commands, when the point is simply to drop into a root shell, which is a facility provided directly by "sudo", if you'd only read the manual page and learn its options.
Nothing will stop you from invoking "sudo -s" without a password, without another fork/exec, without another suid utility carrying a significantly different authentication model.
I admit that in the context of doing "ls /sys/module" it's likely not a huge problem, but I do (in my gut) feel that for running an elevated command, it's cleaner to just drop in as actual root, instead of masquerading as root.
The options I've memorized over the years are the ones I've used the most often, and this inertia can lead to ignorance, unless I periodically revisit the manual page to see what else can be done.
Every IT/CS instructor will tell you that your source of truth is the vendor's documentation. Don't waste your time Googling Stackexchange when the manual pages are available right on the system, on a website, or however. The manual pages are written by the developers and tech writers to specifically tell you how to use these commands.
You can either "cat for clarity" for the rest of your career, or you can learn new methods like shell redirects, "tee(1)", "exec <file; while read var; do cmd; done". I wouldn't be surprised if people start their careers thinking that "cat" is just for starting up a pipeline. Other students may be taught that "cat" is an elementary way to just put file contents on their terminal screen, and then they'll subsequently learn how "more(1)" is superior in this regard.
"When all you have is a hammer, everything looks like a nail."
Essentially a "maybe, depending on what your OS policy is", proving that your comments are less than helpful.
https://manpages.ubuntu.com/manpages/noble/en/man8/sudo.8.ht...
-E, --preserve-env
--preserve-env=list
-H, --set-home
-i, --login
-s, --shell
The sudoers policy subjects environment variables passed as options to the same restrictions as existing environment variables with one important difference. If the setenv option is set in sudoers, the command to be run has the SETENV tag set or the command matched is ALL, the user may set variables that would otherwise be forbidden.
So what you're proposing to do is to escalate privilege using "sudo"s security model and configuration, which may add, suppress, or alter environment variables, as well as SELinux and resource limits and cgroups or whatever, and then have a second go-round through "su" may alter the environment further, making for an unpredictable interaction. Hopefully it's all harmonized through PAM, but all you wanted is an interactive shell. Why try to justify this copy-paste idiom?
In fact, I could rewrite your original snippet as
sudo ls /sys/module