by mjg59 on 4/7/21, 6:03 PM
What was notable in this case was that Google disclosed this issue to Intel, and Intel then took responsibility for public disclosure. Intel then proceeded to mail patches to public trees without flagging them as having any security relevance, posted a public disclosure despite the patches only being in pre-release kernels and claimed that affected users should upgrade to 5.9 (which had just been released) which absolutely did not have the patches fixed.
Coordinating disclosure around security issues is hard, especially with a project like Linux where you have an extremely intricate mixture of long-term support kernels, vendor trees and distributions to deal with. Companies who maintain security-critical components really need to ensure that everyone knows how to approach this correctly, otherwise we end up with situations like this where the disclosure process actually increased the associated risks.
(I was part of Google security during the timeline included in this post, but wasn't involved with or aware of this vulnerability)
by fulafel on 4/7/21, 5:08 PM
I wonder what effect self selection bias has in people who end up writing hand crafted complex parsing code in C for untrusted data in ring 0. You either have to believe that it's doable to get right or that it doesn't matter much if you don't, or "it's not my worry".
by BenoitEssiambre on 4/7/21, 7:14 PM
I should be safe. After the latest ubuntu update, my bluetooth refuses to connect.
by ipsin on 4/7/21, 6:08 PM
by dopu on 4/7/21, 8:22 PM
This might be a pretty naive question, but: in a hypothetical world where the vast majority of systems programming is done in "memory safe" langs, what would most vulnerabilities look like? How much safer would networked systems be, in broad strokes?
by 1-6 on 4/7/21, 5:44 PM
Sometimes I wonder if driver support such as Wi-Fi on FreeBSD is terrible by design. That OS has almost no attack surface.
by r1ch on 4/7/21, 8:30 PM
I'm curious how the "BadChoice" vulnerability did not get picked up by a static analyzer. Only initializing part of a structure should be very easy to catch.
by ndrake on 4/7/21, 4:08 PM
by phab on 4/7/21, 10:25 PM
Clearly I'm missing something - in BadKarma, why does the compiler not baulk at sk_filter being passed a struct amp_mgr* instead of a struct sock* as expected? A type confusion like that ought to be prevented during typecheck, no?
by orblivion on 4/7/21, 10:34 PM
So, tl; dr upgrade our kernels? Or is there more?
(This would be useful to have on Google's site here, but I understand if it's supposed to be for academic audiences)
by young_unixer on 4/7/21, 10:44 PM
Does anyone pay bounties for this kind of vulnerability in the kernel or in widely used low-level libraries? I mean legally, not in darknet markets.
by fithisux on 4/8/21, 5:51 PM
BT spec is huge. We need smaller and developer friendly specs.
by dilippkumar on 4/7/21, 11:56 PM
OpenBSD user: sips tea
by topspin on 4/7/21, 4:53 PM
This first appeared six months ago.
by baybal2 on 4/7/21, 5:15 PM
WiFi stack, and drivers would be even more scary to look at.
by Alekhine on 4/7/21, 6:44 PM
What kinds of attacks could we actually see with this? Servers don't use bluetooth and desktops often don't, but Linux laptops and IOT devices often do. With Linux laptops being a rarity and IOT devices already being insecure pieces of crap whose value to a serious attacker is questionable, I fail to see how relevant this is for the average tech user.
by tediousdemise on 4/8/21, 2:55 AM
TLDR; horrendous security exploits uncovered in code written in known unsafe language.
The code is an utter shitshow, inviting disaster through seemingly normal use of the language. It contains a mess of malpractices that make any modern C++ or Rust developer cringe: goto, memcpy, naked pointers, type unsafe casts, raw loops, using malloc to allocate memory for input buffers.
Why do people continue to juggle chainsaws? I think it's fear of new things, fear of change. Old habits die hard.
by aasasd on 4/7/21, 5:09 PM
Look, it's 2020s. I'm getting put to sleep by stuff like this. You gotta amp the names up to ‘Genital Grinder’ or ‘Vomited Anal Tract’ if you want people to pay attention.
by everdrive on 4/7/21, 7:26 PM
My decision not to have Bluetooth pays off again!
by baybal2 on 4/7/21, 4:43 PM
What to say, very solid work
by rvz on 4/7/21, 6:27 PM
Would be even more worrying if macOS or iOS also had these sort of bugs in the bluetooth stack. Plenty of iOS/Mac users using AirPods these days since Apple removed the headphone jack. Bluetooth is already turned on in the default install.
Going to put this comment here as a reference to quote later when I see a zero click RCE for iOS devices using Bluetooth for drive-by exploitation.
by phendrenad2 on 4/7/21, 7:52 PM
Every week there's a new vulnerability in the Linux kernel - is it time to admit that (A) the "many eyes" theory is disproven (B) the Linux kernel has evil malware agents "oopsing" bugs in exactly as fast as we discover them?