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)
To me it feels like we owe Google a lot for what they are doing to find security vulnerabilities. Did companies do stuff like this before Google's Project Zero?
from the guys who brought you "the spectre patch in the kernel thats disabled by default" and "ignore your doubts, hyperthreading is still safe" comes "the incredible patch built solely around shareholder confidence and breakroom communication"
It seems odd that they would have notified Intel rather than the security team, given how poorly Intel has handled disclosures in the past... Its good that they do note that "The Linux Kernel Security team should have been notified in order to facilitate coordination, and any future vulnerabilities of this type will also be reported to them"
Thank the lord for distros like Fedora. They deal with security and other issues, and are big enough that if Intel tried to sneak something past, almost assuredly Intel's engineers working on Red Hat would have noticed something.
It's like Intel is releasing the same CPUs with new boxes and naming hoping that people won't find out :-) That company has become such a failure. What happened 5 years ago?
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".
It's not like NASA sent a rover, written almost fully in C, to Mars. It's not like billions of cars and even more billions of their ECUs are written in C. It's not like the firmware of the keyboard you're writing your comment on, or even the OS/browser you're using is written in C. C bad, Rust good.
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?
> "A recent study[1] found that "~70% of the vulnerabilities addressed through a security update each year continue to be memory safety issues.” Another analysis on security issues in the ubiquitous `curl` command line tool showed that 53 out of 95 bugs would have been completely prevented by using a memory-safe language. [...]"
Likely we'll have less 'os-level' pwns, but to be fair these aren't really the most exploited class of vulnerabilities today anyway. I'm just as effective doing a sql injection and stealing your client's PII if you have or don't have your bluetooth stack written in a lang that prevents some memory corruption exploits from being feasible, and that's the actual goal of most attacks.
You're going to get owned in future by people obtaining creds to important stuff (say, aws creds) and by crappy userspace applications, we can hope that OS security continues to improve but even if it does get bulletproof the story is far from over while our apps are all piles of garbage.
Web development is done mostly using "memory safe" languages and we can see that it is far from being secure. The list looks like: https://owasp.org/www-project-top-ten/
Which is not to say that "memory safety" is not a significant issue in C/C++. I wonder why wuffs [1] is rarely used in C projects to parse untrusted data given that it can be translated to C.
Just adding slices to C would kill a very large proportion of bugs, but there are dimishing returns after a certain amount of safety because you start to reach the end of dangerous code, and into bad code (e.g. you forgot to check the password entirely): You can still catch the latter type of bug using typesystems and formal verification but it's not easy, whereas catching memory safety bugs even using a sanitizer atop of regular C code is actually extremely well-trodden ground now.
One way to count is to count all the bugs that get fixed. Another would be to consider the security issues with the greatest impact on the past year. Solarwinds, and probably the Exchange vulns, would be my vote. Which would a memory safe language have prevented?
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.
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?
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.
Android has a Linux kernel and uses it's stack.
As a person in the field I can tell you that the IoT is not just smart lights. There are starting to appear smart sensors or even car infotainments which are Linux inside. Sure, car infotainments are not controlling the engine power or throttle but it is for sure requesting engine start up or displaying the glass cockpit in modern cars. Otherwise how do you think you can turn on the car with the new fancy app?
From what I see we are going back from general computers running an old version of windows xp or red hat into special purpose Linux system on a module devices.
Many desktops nowadays come with wifi, and wifi cards often also have Bluetooth. I just looked at a nearby Dell desktop (which came with wifi built-in), and it shows Bluetooth as enabled.
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.
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.
dont forget its gotta have a vector graphic mascot and a custom TLD from a design team of MFA students. if the disclosure page doesnt take over my mouse like a new iPhone release website and include a youtube video i just cant be bothered.
> 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.
Hmmm. Either BrokenTooth or BlenderWave are apropos to the year.
[+] [-] mjg59|5 years ago|reply
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)
[+] [-] qwertox|5 years ago|reply
[+] [-] nimbius|5 years ago|reply
from the guys who brought you "the spectre patch in the kernel thats disabled by default" and "ignore your doubts, hyperthreading is still safe" comes "the incredible patch built solely around shareholder confidence and breakroom communication"
EDIT: spectre, not meltdown. oops.
https://www.theregister.com/2018/11/20/linux_kernel_spectre_...
[+] [-] drewg123|5 years ago|reply
[+] [-] greatgoat420|5 years ago|reply
[+] [-] varispeed|5 years ago|reply
[+] [-] fulafel|5 years ago|reply
[+] [-] athrowaway3z|5 years ago|reply
{ .... }
[+] [-] ptsneves|5 years ago|reply
[+] [-] 0xdeaddeaf|5 years ago|reply
It's not like NASA sent a rover, written almost fully in C, to Mars. It's not like billions of cars and even more billions of their ECUs are written in C. It's not like the firmware of the keyboard you're writing your comment on, or even the OS/browser you're using is written in C. C bad, Rust good.
[+] [-] BenoitEssiambre|5 years ago|reply
[+] [-] dkarras|5 years ago|reply
[+] [-] ipsin|5 years ago|reply
[1] https://google.github.io/security-research/pocs/linux/bleedi...
[+] [-] dopu|5 years ago|reply
[+] [-] hezag|5 years ago|reply
> "A recent study[1] found that "~70% of the vulnerabilities addressed through a security update each year continue to be memory safety issues.” Another analysis on security issues in the ubiquitous `curl` command line tool showed that 53 out of 95 bugs would have been completely prevented by using a memory-safe language. [...]"
[0]: https://security.googleblog.com/2021/02/mitigating-memory-sa...
[1]: https://github.com/Microsoft/MSRC-Security-Research/blob/mas...
[+] [-] cyberpunk|5 years ago|reply
You're going to get owned in future by people obtaining creds to important stuff (say, aws creds) and by crappy userspace applications, we can hope that OS security continues to improve but even if it does get bulletproof the story is far from over while our apps are all piles of garbage.
At least, that's what I recon'
[+] [-] citrin_ru|5 years ago|reply
Which is not to say that "memory safety" is not a significant issue in C/C++. I wonder why wuffs [1] is rarely used in C projects to parse untrusted data given that it can be translated to C.
[1] https://github.com/google/wuffs
[+] [-] mhh__|5 years ago|reply
[+] [-] tedunangst|5 years ago|reply
[+] [-] gostsamo|5 years ago|reply
[+] [-] Thaxll|5 years ago|reply
[+] [-] 1-6|5 years ago|reply
[+] [-] rollcat|5 years ago|reply
[+] [-] 1-6|5 years ago|reply
[+] [-] r1ch|5 years ago|reply
[+] [-] ndrake|5 years ago|reply
[+] [-] phab|5 years ago|reply
[+] [-] loeg|5 years ago|reply
[+] [-] orblivion|5 years ago|reply
(This would be useful to have on Google's site here, but I understand if it's supposed to be for academic audiences)
[+] [-] young_unixer|5 years ago|reply
[+] [-] fithisux|5 years ago|reply
[+] [-] dilippkumar|5 years ago|reply
[+] [-] topspin|5 years ago|reply
[+] [-] gerdesj|5 years ago|reply
[+] [-] baybal2|5 years ago|reply
[+] [-] atat7024|5 years ago|reply
[+] [-] Alekhine|5 years ago|reply
[+] [-] ptsneves|5 years ago|reply
From what I see we are going back from general computers running an old version of windows xp or red hat into special purpose Linux system on a module devices.
[+] [-] cesarb|5 years ago|reply
[+] [-] outworlder|5 years ago|reply
[+] [-] _haoa|5 years ago|reply
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.
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] aasasd|5 years ago|reply
[+] [-] nimbius|5 years ago|reply
[+] [-] formerly_proven|5 years ago|reply
[+] [-] BoardsOfCanada|5 years ago|reply
[+] [-] IncRnd|5 years ago|reply
Hmmm. Either BrokenTooth or BlenderWave are apropos to the year.
[+] [-] neals|5 years ago|reply
[+] [-] throwaway889900|5 years ago|reply
[+] [-] everdrive|5 years ago|reply