15 ms·
Some remotely exploitable Linux kernel WiFi vulnerabilities
- BluSyn 4y agocode diff: https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?h=for-next&id=e7ad651c31c5e1289323e6c680be6e582a593b26 https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wir...
- NickGerleman 4y agoI'm surprised there were not compiler errors for unreachable code, in the cases where the code was returning directly before a goto. Edit: Looks like GCC removed the warning because it was unreliable. Clang and MSVC seem to be in better shape. https://gcc.gnu.org/legacy-ml/gcc-help/2011-05/msg00360.html https://gcc.gnu.org/legacy-ml/gcc-help/2011-05/msg00360.html
- account42 4y ago> Edit: Looks like GCC removed the warning because it was unreliable. Clang and MSVC seem to be in better shape. https://gcc.gnu.org/legacy-ml/gcc-help/2011-05/msg00360.html https://gcc.gnu.org/legacy-ml/gcc-help/2011-05/msg00360.html That is an odd position when -Wstringop-overflow also highly depends on the optimizer (and will frequently generate false positives!) but not only remains in GCC but is enabled by default (even without any -Wall/-Wextra). Things like this are why its pays to compile your project with as many compilers as possible (as well as static analysis tools).
- galangalalgol 4y agoDon't forget asan and ubsan. That requires good unit teat coverage to work though.
- londons_explore 4y agoTheres a lot of bugfixes there... And some are obviously correct... But others would require a lot more understanding of the code to be sure they're correct. Someone should go through this with a keen eye to check the fixes are actually correct, and aren't just making the fuzzer stop alerting while leaving a more subtle vulnerability open.
- UncleMeat 4y agoYeah the fact that the kernel has changes like this with such minimal testing is the reason why we see regressions in these kinds of bugs all too often.
- prima-facie 4y ago> anybody who uses WiFi on untrusted networks So is this for public/open Wifi networks only? Or is it for any wireless network where you do not control the gateway?
- XMPPwocky 4y agoat least one of the RCE vulns seems to be exploitable even without connecting to any network (reachable via probe response handling).
- e12e 4y agoRecommend that people click through and read the comments, in particular the (now) top thread, in part: https://lwn.net/Articles/911071/ https://lwn.net/Articles/911071/ >> anybody who uses WiFi on untrusted networks > It's actually worse than that - you just have to be scanning (though one of the issues requires P2P functionality to be enabled). > So basically it's just >> anybody who uses WiFi > unfortunately. And: > Sorry, it took me longer than expected but I just posted PoCs + logs here: https://www.openwall.com/lists/oss-security/2022/10/13/5 https://www.openwall.com/lists/oss-security/2022/10/13/5 > Most of the vulnerabilities were introduced in 5.1/5.2.
- londons_explore 4y ago> > anybody who uses WiFi It's worse than that - android kernels process beacon frames even if wifi is disabled. So you should be worried about this if you have an android 11/12 phone, even if you don't use wifi. Linux desktop/laptop users should be worried if they have wifi enabled, even if not connected to a network.
- dontbenebby 4y ago>It's worse than that - android kernels process beacon frames even if wifi is disabled. >So you should be worried about this if you have an android 11/12 phone, even if you don't use wifi. Is this issue (RCE even with wifi off across a huge swathe of devices ) common to many vulnerabilities, and we're just discussing this one because it hit the front page, or is this vulnerability especially... egregious?
- derelicta 4y agoguess its gonna be easier than ever to root one's android phone.
- nisa 4y agoCould someone more knowledgeable than me comment if this is as worse as it looks? As I understood the issues, this will probably lot's of "fun". You can broadcast the pcap files with any monitor mode capable wifi router. Luckily it's 5.1+ so most devices run very old vendor patched kernels and are probably not affected but at least for causing havoc this is really bad. As one issue is using beacon frames just a scan for networks should be enough for a crash. So you can at least crash and maybe exploit any device running recent Linux that scans for wifi networks. I'm not sure how it's possible to do over the air remote code execution but I guess people are working on this.
- eknoes 4y agoI found the vulnerabilities, but am no expert for the Wifi stack. DoSing is now "easy" as you say, just send those frames and a Linux computer that is currently listening to the network (e.g. scanning for networks) and thus processes the Beacon frames will at least crash. It might be the case that some wifi chips will filter those invalid frames or crash themselves, that depends on the actual hardware / firmware. The victim must not be connected to a malicious AP or similar, so there is no requirement for tricking a user into something. RCE is not trivial at all, but due to the nature of the different faults, might be possible. Therefore, see e.g. Mathy Vanhoef who discovered several impressive Wifi vulnerabilities in the past: https://twitter.com/vanhoefm/status/1580675615992451072 https://twitter.com/vanhoefm/status/1580675615992451072
- deleted 4y ago[deleted]
- tapper 4y agoFYI Fixes are now in openWrt master 21.x and 22.x branches. New bin files will be posted soon. Or you can build from the git.
- cesarb 4y agoFrom a quick look at the openwrt home page, they had really bad timing this time: they had just released an important security release two days ago (on the 12th), one day before this new set of vulnerabilities was announced yesterday (on the 13th).
- userbinator 4y agoLooks like these are all in mac80211. I'm not 100% familiar with the intimate details of 802.11 but I have read the relevant parts of the standard, at least enough to RE some drivers, and a lot of things were clearly designed to be fixed and of a definite size so as to be implementable on a highly constrained embedded environment, so to see things like use-after-frees appear is a little disappointing.
- hardware2win 4y agoWeekly news of memory related CVE. Keep using unsafe langs. What will be there in next week? CVE in Chromium? At this point betting sites should add category for that kind of games. I do wonder what people of future will think about this: "So they had research indicating that a lot of issues were related to memory, had technology which significantly reduces this issue, but they still kept doin mess for years?" https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe-systems-programming/ https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe... https://microsoftedge.github.io/edgevr/posts/Super-Duper-Secure-Mode/ https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec... https://www.chromium.org/Home/chromium-security/memory-safety/ https://www.chromium.org/Home/chromium-security/memory-safet... Memory issues and JIT (browsers) are two things that are responsible for disgusting amount of security issues
- thegeomaster 4y agoThis is naive. You cannot rewrite the entirety of the Linux kernel in another language overnight. You'd have years at least until it becomes production-ready. Not to mention the performance and memory use will be worse. Certainly the situation can and should be better, but adopting this "it's so easy, how does nobody see it?" attitude helps no one.
- green_on_black 4y agoI mostly agree, but I think I would have read the comment differently. I've seen C++ people have a strong distaste towards Rust for various reasons and don't exactly care too much about the "memory safety" part. Which is... unfortunate. So while it might be "beating a dead horse", the horse isn't even dead.
- hardware2win 4y agoYou're right. People need to be aware how mem. safety affects security in critical software like Chromium or Microsoft's.
- AshamedCaptain 4y ago
- fsflover 4y agoFortunately, on Qubes OS, only the networking VM can be exploited like this, and it will be clean again after its reboot.
- lostmsu 4y agoHow's GPU support in Qubes these days? (Nvidia, CUDA)
- orblivion 4y agoI installed 4.1 and only my firewall VM is disposable. Wouldn't that mean my net VM could still have an exploit that leaves something in the home directory? (Would be nice if it was easier to trash and rebuild it).
- fsflover 4y agoYou can choose sys-net to be a disposable during the install. It's not the default. You can also make it a disposable manually: https://www.qubes-os.org/doc/disposable-customization/#using-named-disposables-for-sys- https://www.qubes-os.org/doc/disposable-customization/#using... Beware that your WiFi password will be forgotten every VM reboot (but there is a workaround on the forums).
- orblivion 4y agoThank you! (Yes I forgot that it was an option I chose; I probably went with the defaults, not knowing the implications of deviating)
- Syonyk 4y agoIt's possible, but I believe the design is such that sys-net is untrusted, so an exploit there is no more risk than any other use of an unencrypted connection on the network. But it sure looks like it was a wise idea to spend the resources on isolating network hardware!
- xani_ 4y agoEh, it didn't get cutesy name like BadWiFi, won't be that bad /s
- dspillett 4y ago“beacown” apparently: https://github.com/PurpleVsGreen/beacown https://github.com/PurpleVsGreen/beacown Though that may not be a generally used name as yet.
- boricj 4y agoCan we please stop running network drivers and network stacks in kernel mode by default? It's 2022 and we've got more than enough compute power nowadays that the performance hit for running these in user-land is negligible for most use cases. Smartphone, tablet or laptop users usually do not need the level of performance that requires running that stuff in the kernel when browsing the web. I get that there are some use cases where performance really matters to the point where kernel network stack and drivers make a difference (high-throughput and/or low-latency services running on servers, high-performance routers...), but that should not be the default for everyone.
- alfiedotwtf 4y agoObligatory comment: https://www.oreilly.com/openbook/opensources/book/appa.html https://www.oreilly.com/openbook/opensources/book/appa.html
- boricj 4y agoNote that the Tanenbaum-Torvalds debate was in 1992, over thirty years ago. The security of computer systems might have improved since then, but the fallout of security issues has massively increased. Managing your bank accounts wirelessly on the Internet from anywhere in the world with a thin, battery-powered device that fits inside your pocket was a pipe dream (and no one could've possibly imagined that an Internet-ready smart toaster could compromise it and steal your money on your accounts).
- dijit 4y ago1) Many will cry about that performance hit (including me). For over a decade our computers have gotten faster marginally, but our software has gotten slower at a greater rate. You can barely navigate the web now with a new low end computer (that isn't a Chromebook). Most on this site won't care though because our machines cost $2,000+ and the web is Fine(tm); many folk aren't buying anything over $300 though. 2) These are memory bugs, so the introduction of Rust into the kernel could help us here potentially, no need for an architectural revolution.
- sva_ 4y agoSeems like most of these got introduced in 5.1/5.2/5.8 and fixed in 5.19.14.
- cesarb 4y agoI don't see any of these fixes in 5.19.14; in fact, Fedora has just released a 5.19.15 with these fixes manually applied on top of it. The stable release with these fixes will probably be 5.19.16.
- sva_ 4y agoIt seems like you're right. I misunderstood something. That's worrying. ArchLinux seems to also have it patched in 6.0.1-arch2-1 though[0]. [0] https://security.archlinux.org/ASA-202210-2/generate https://security.archlinux.org/ASA-202210-2/generate
- hotcoffeebear 4y agoI think Fedora 37 beta already use 5.19.15, the stable release in few days afaik.
- cesarb 4y agoAll currently updated Fedora releases use the same kernel release, that is, every kernel update is released to all currently updated Fedora release at the same time (with slight timing differences for the migration from "testing" to "stable"). If you look at https://bodhi.fedoraproject.org/updates/?packages=kernel https://bodhi.fedoraproject.org/updates/?packages=kernel right now you see 5.19.15-x01 for Fedora 35, 36, and 37 (the 5.19.15-x00 packages didn't have these fixes, the 5.19.15-x01 packages have them).
- cesarb 4y ago> The stable release with these fixes will probably be 5.19.16. Updating my own comment (too late to edit), that release is now out with the fixes. The full set of stable releases with these fixes is: 6.0.2, 5.19.16, 5.15.74, 5.10.148, and 5.4.218 (source: https://lwn.net/Articles/911272/ https://lwn.net/Articles/911272/).
- kramerger 4y agoStupid question, but how come this has not been embargoed? Seems like a pretty major vulnerability that affects tons of devices.
- fulafel 4y agoIs there reason to believe it wasnt? The oss-security mail message would seem consistent with the fixes having been prepared under embargo.
- deleted 4y ago[deleted]
- christophilus 4y agoNice. Just in time for a long weekend on public WiFi with my Linux laptop.
- WelcomeShorty 4y agoMuch better link: https://github.com/PurpleVsGreen/beacown https://github.com/PurpleVsGreen/beacown
- fsflover 4y agohttps://news.ycombinator.com/item?id=33201478 https://news.ycombinator.com/item?id=33201478
- ByThyGrace 4y agoHmm does anyone know if there is a site/community/service that keeps track of backports fixing CVEs for different Linux distros?
- Jon_Lowtek 4y ago> The 6.0.2, 5.19.16, 5.15.74, 5.10.148, and 5.4.218 stable kernel updates have all been released. Among other things, these updates contain the fixes for the recently disclosed WiFi vulnerabilities. ~~ LWN.net