{ .... }
I advise you to read his Turing award speech from 1981.
And indeed "the system is to blame" in that it's hard to get drivers using safe techniques into the Linux kernel, and Linus is famously anti-security. But I think for the individual programmer, they still end up choosing one of the above 3 mental models.
So I still think it would be interesting to know how people think about security when writing parsers in C in ring 0 for Linux drivers that exposed by default in billions in devices.
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.
Re Rover code and ECUs - this is the difference between safety critical code and security critical code at the attack surface.
The first kind deals primarily with "don't keel over or go crazy when natural phenomena throws unexpected circumstances at you", the second deals with inputs crafted by intelligent adversaries who can see your code and test & iterate attacks to exploit any flaws they uncovered through analysis or experimentation against your implementation. (Of course if we nitpick, an intelligent attacker is a natural phenomenon.)
Those have tons of exploitable bugs!!
NASA rovers and car ECUs have minimal people looking to exploit them, so I'm not overly convinced they're exploit free either.
I'm not a Rust evangelist or even a user, but the current paradigm of "THIS TIME, we'll write safe, complex, performant C/C++ code properly" isn't the solution, nor is manually squashing bugs one by one.
The solution seems to be a combination of improving the tooling around existing C\C++, and starting new projects in safer languages when possible.
Your holes are its seducing.
It slays from a distance,
You're on the list for
E-XE-CU-TION
GAAAAAARRRRRRRGH!!!
Hmmm. Either BrokenTooth or BlenderWave are apropos to the year.
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)
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_...
I'm not sure to what you are referring to here.
I was one of the people who worked on the Linux PTI implementation that mitigated Meltdown. My memory is not perfect, but I honestly don't know what you're referring to.
> "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...
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'
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.
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.
For example I recall reading there was an example of a car which wouldn't trigger collision avoidance during a phone call because it was erroneously triggering the breaks to a very small degree and the logic was not to trigger the breaks when the user was already braking.
There is every reason to believe security is as mediocre on cars as elsewhere.
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.
They don’t add features that break backward compatibility, or features that sacrifice runtime performance especially if you don’t use those features. Most new features added to C++ are actually just additions to the STL, which you aren’t forced to use.
It is an open standard, so there is plentiful competition in the realm of compilers. Rust only has 1 so you are SOL if you don’t like something or if the project goes bust one day.
The way I see it, all those vulnerabilities prove the opposite. If there were no "many eyes", I doubt most of those vulnerabilities would have been exposed to the public at all. But I bet that malicious actors would still be using those.
That argument you made reads similar to "hospital theory is disproven, because whenever we get more hospitals and doctors, more people end up with a diagnosis".
The only conclusion people should be drawing from the last 20 years of security being taken seriously is that writing secure software is hard, finding bugs is hard, and business model doesn't really matter.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
If so, they wouldn't want the public to know why they are or that they are "buying and using cyberweapons" - both to stay effective and for political/international relation reasons. So probably hard to find or contact them.
I wonder how often unsolicited emails are sent to *@cia.gov with subject: "I have RCE on ___, wanna buy it?" and how they respond.
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.
[1] https://google.github.io/security-research/pocs/linux/bleedi...
(This would be useful to have on Google's site here, but I understand if it's supposed to be for academic audiences)
:format(jpeg):mode_rgb():quality(90)/discogs-images/R-367385-1229040509.jpeg.jpg){kind=link}