Slashdot Mirror
Security Problems Are Primarily Just Bugs, Linus Torvalds Says (iu.edu)
Linus Torvalds, in his signature voice: Some security people have scoffed at me when I say that security problems are primarily "just bugs." Those security people are f*cking morons. Because honestly, the kind of security person who doesn't accept that security problems are primarily just bugs, I don't want to work with. Security firm Errata Security has defended Linus's point of view.
Security by obscurity, government backdoors, etc. Those are not bugs.
#DeleteFacebook
It's true, security problems usually exploit a bug. BUT, in general, there is a systematic problem underneath the bug, which allows a bug in a program to escalate to gain access to root-level systems. So, it's not just a bug, but a bug that is built on a system that does not have security built in.
He is demonstrably wrong. True, some security problems are bugs, but there are also security problems that are bad design choices, that are misconfigurations, that are counting use of old technology (e.g. RSA 1024), that are poor use cases (nobody follows policy, because it is too complex and/or convoluted). You can't secure systems with just code reviews and patching. No way, no how.
The alternative would be "features"
At least when you take into account that people should design security in today. So from the coding angle, pretty much "just bugs". From the testing angle often vastly different, as in functionality testing you check for the presence of functionality, but in security testing you check for the absence of functionality. Individual tests are still pretty similar, but getting test-coverage is very different and a lot more difficult.
Of course, the "just bugs" view also requires that the developers actually understand security. That is far more often not the case as with functionality bugs. Although even with functionality, quite a few coders do not really know what they are doing. So again, not quite the same thing, but also not quite different either.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Security problems are not 'just bugs'. Security mechanisms realizes functionality that's on top of business logic that has to be realized.
For example consider cleaning passed data to prevent SQL injection attacks. No business logic requires the software to do this. If it's not implemented, it's *not* a bug. You only implement data cleaning to prevent the specific attack.
Nevertheless, a lot of security problems are bugs, but not all.
True, but I can think of many developers who build in security problems due to ineptitude. Ignorance is not an excuse.
Assuming he has a requirement for security then of course he's right
You can word it the way you want. If it's not secure, it's not secure.
I tend to rant.
https://www.theregister.co.uk/...
I don't read your sig. Why are you reading mine?
I thought that Linus personally approves all the changes to the kernel. So didn't he approve the changes he is complaining about?
I couldn't agree more with Linus. It's not like we know each other or have Thanksgiving together; he's right in his own non-PC way. As long as we're talking about a bug not being: 1) maliciously intended code or put there 'on purpose', 2) functionality or operability that falls into as not-as-advertised, or blatantly didn't follow an RFP or standard or 3) hell, stuff that was just overlooked, seemingly over/under-engineered or ego-over-good-code.
...I'm sure there's a few more mental dice-up catalogs to expand on, but at the end of the day, that's how I'm looking at it. Anyone who has written any sort of code with any language any any level has dealt with this. Unless, it's extremely intended, it's a bug to me (what do the new kids call it these days? A glitch?) --- then we can put all the metadata and sub-categories onto that logical gaff of a bug as we want at that point in terms of 'where' it falls so some Agile scrum party can have a scrum-stick-beating party to organize what is prioritized over what.
The question was *how* equifax was hacked. Was it through a measure that this would have prevented? Probably not, it was probably much more mundane.
The patch may be a nice improvement and ultimately a good idea, but it's a hardening improvement, not a fix for a specific vulnearabilty, so caution must be taken. You can't just invoke the 'security' card as a 'nothing else matters' when dealing with adding security features.
Security vulnerablities are urgent, security mitigation features are important, but less urgent and are worth the time to get them *right*. One thing is to not break function, but also to make sure that feature is comprehensive, lest you end up with a myriad of complex code to paste over the gaps of the last thing.
XML is like violence. If it doesn't solve the problem, use more.
True, but I can think of many developers who build in security problems due to ineptitude. Ignorance is not an excuse.
Ineptitude is a bug. The resolution just involves a hammer to the face instead of an IDE.
Security by obscurity
All data security is essentially security through obscurity. Vault combinations, cryptography, keys, etc are all rely on various forms of information that is not widely known. The security comes through obscure information. Now there are forms of "security" through obscurity which are trivial to figure out and thus effectively worthless but even the most robust cryptography is still security through obscurity at its core.
The context of the statement is that somebody submitted changes to the kernel and he denied the request.
Somebody wanted to add "security" code that would kill of a process, or even the whole kernel, if it detected something that might be a security concern. So with the proposed change, programs would crash without warning if this new code detected a possible security problem. Most of what it detects aren't attacks, though, they are just bugs in the software that need to be tweaked to explicitly follow security rules. The new security code should first warn about these bugs rather than crashing the system, Linus said. Quoting him:
So the hardening efforts should instead _start_ from the standpoint of
"let's warn about what looks dangerous, and maybe in a _year_ when
we've warned for a long time, and we are confident that we've actually
caught all the normal cases, _then_ we can start taking more drastic
measures".
His world being the world of the Linux Kernel. When you use this context then of course any security breach is due to a bug, simply because, well, what else should it be?
Outside of that context... no.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Errata Security confirmed that they will not be changing their name to Much More Than Just Errata Security. LOL.
Custom Solvers 2.0 = Alvaro Carballo Garcia = varocarbas.
Thereâ(TM)s âoeyou forgot to check array bounds hereâ bugs, and then thereâ(TM)s âoeyour entire design is fundamentally fucked and insecureâ bugsâ¦
Features....to certain 3 letter agencies
And then there's "it's 2017 and we've never heard of UTF-8" bugs.
You suck terrible at Finnish, that's for sure.
Is there any objective and consistent working definition and/or test of "bug" versus "bad design"? I suspect there is a lot of gray area such that Laynes Law will reign over such discussions.
Table-ized A.I.
Linus has been going back and forth with grsecurity about the patch set they have put out. All I know is that over the years all the kernel bugs that have allowed for local and remote stack overflows, my systems have not been compromised because of the use of the grsecurity patches. It's a shame that the guy who puts out the grsec patches is trying to charge money for them, but its also a shame that some of these standard features like no-exec-stack patch and trusted-path-execution patches have not been implemented into the mainline kernel tree over two decades.
I agree with Linus in this specific case. Killing the kernel is not an acceptable practice because some program did something questionable. It's probably some shit code that did something bad or unintentional. If every time the kernel panicked and crashed, you better not surf the web. Some shitty flash ad will crash your kernel a few times a day.
This succinctly summarizes what I've been trying to relate to others for quite some time.
"Active" security is generally treating the symptoms of poor quality software. selinux, "SafetyNet," virus scanners .. all of these things, while masking some issues, add code complexity and expose a larger attack surface.
Simple, clean, elegant, and obviously correct code (and that includes design) needs no complex "security" bolted on. It just needs to function as documented.
A government is a body of people notably ungoverned - AC
Granted from Linus' kernel perspective, _MOST_ security problems are caused by bugs. Userspace has far more bugs, and proportionally more caused by poor design & implementation. However, loadable kernel modules are a security hazard that has been designed-in.
Except that permission has to be granted to load a kernel module. It doesn't happen by accident (in a normally configured system)
So I totally agree with Linus on this one. I mean, just look at the bug that is Systemd. It's a security hole waiting to happen.
`insmod` is tough? Modifying a commonly used module, perhaps one loaded later (vfat)? Modules do have a checksum, easy to fix. They do not have any crypto-signing which might verify integrity.
... Linus doesn't mince words when it comes to pointing out bad software development.
As usual, he's right.
And before you object, think for a moment if it could actually be the case that he knows what he is talking about and may even be a better programmer than you. And that your should maybe listen to what he has to say.
My 2 cents.
We suffer more in our imagination than in reality. - Seneca
I love Linux. It's an awesome OS. I like Linus a lot too. He's contributed a great deal to computing. However, calling people names doesn't really fix anything. On this particular issue I feel that he's wrong in his assessment as well. There is a distinct difference between a bug that causes a failure in functionality as opposed to a bug that exposes a system from a security standpoint. He's right in that both are bugs, but the consequences are much higher when it is security related, and that's why we treat them differently. That being said there is also a well established divide between security analysts, and developers. As a developer we just want stuff to work, and often times security makes that difficult. As a security analyst we want to keep the system secure (in some cases need to - think compliance), and often times developers make that difficult. I wear both hats in my position so I see it all the time. Ultimately it's in everyone's interest to work together to create code that both works, and is secure. Engaging in a pissing match does nothing useful.
I don't believe in karma, I just call it like I see it.
No preview on mobile. :(
I may dislike systemd, and the direction that it is pushing things, but that isn't sufficient to justify calling it a bug. A flat head screw isn't a bug instead of a phillips, it's just designed for different applications.
I think we've pushed this "anyone can grow up to be president" thing too far.
Perspectives will vary by profession. Once you get outside of software development, I suggest that most security problems are the result of either failing to promptly update software, failure to properly configure software, or incomplete risk analysis. For example:
The Pentagon leak appears to be a a failure to properly configure access controls.
Equifax was a failure to update software after a bug was found/fixed.
Fukushima was a failure to consider the risks during the design process.
Linus' perspective is from that of a software developer. I suspect Linus' rant stems from people writing
if ( badinput() ) kernelpanic();
instead of
if ( badinput() ) return(Error);.
As a "security person", I happen to agree with Linus that allowing bad input to result in a denial-of-service attack is rarely the best response.
OpenBSD has promoted this belief for years. The description of their audit process states...
"Another facet of our security auditing process is its proactiveness. In most cases we have found that the determination of exploitability is not an issue. During our ongoing auditing process we find many bugs, and endeavor to fix them even though exploitability is not proven. We fix the bug, and we move on to find other bugs to fix. We have fixed many simple and obvious careless programming errors in code and only months later discovered that the problems were in fact exploitable. (Or, more likely someone on BUGTRAQ would report that other operating systems were vulnerable to a `newly discovered problem', and then it would be discovered that OpenBSD had been fixed in a previous release). In other cases we have been saved from full exploitability of complex step-by-step attacks because we had fixed one of the intermediate steps."
it is great to see that "kinder gentler Linus" has gone away and good old "kick 'em in the ass Linus" is back.
Linus' outrageous remarks serve kernel development well
Nobody said it was "tough", the GP wrote that it requires permissions. If you have root, loading a module is not really the most pressing of your security concerns.
While the kernel may perform ASLR on itself, it's primarily to protect applications. Also, if you weren't an illiterate shitbag, you'd know that Linus is talking about patches that cause programs to be killed if they trigger bugs in the kernel. All Linus wants is for warnings to be generated instead, so those bugs can be fixed. ASLR doesn't crash programs. On purpose, anyway.
You're a bug. Here's to hoping someone squashes you.
His statement might be right (and probably is) but there is no need for him to express himself that way. He's not a teenager anymore, he's in his late 40s and ought to be able to better control his impulses (or even be centred enough not to have them in the first place). His words would carry far more weight of he expressed himself more maturely.
Got to read Linus' comment in context of his post, otherwise it's a gross generalization where you're just arguing about semantics and opinions.
A better summarization of what Linus said is: take into account security aspects when designing a feature, so you don't rely on a kernel panic (or exceptions) when some rule is not observed.
Here is something analogous I ran into recently regarding a Java SDK that was not designed with security in mind. Java has a SealedObject to protect sensitive data while in memory - great feature, but then things got messy when it came to dealing with String instances. In Java it is considered bad practice to use String type to represent any kind of sensitive data like passwords because the String is immutable (i.e. it can be visible in the heap for quite a while before getting garbage collected, and if a heap dump is triggered you are screwed). What it boiled down to was the current SDK had signatures like the following:
setPassword(String pwd); // BAD!!!
instead of:
setPassword(char[] pwd); // better!
If the SDK was designed with setPassword(char[]) to begin with, SealedObject library usage would have been much simpler and cleaner - no silly security rules. But thanks to cluelessness of setPassword(String) in the SDK, SealedObject library design became much messier due to security rule to throw an exception whenever it encountered String instances were used to represent sensitive data.
Well, if poor designs are bugs, then yes.
But if the attacker gets root, s/he can keep it, even through reboots and potentially kernel upgrades. For serious intrusion, Ring0 (x86/x64) is the goal, root is just a stepping stone. More to the point, just why do you think OpenBSD removed loadable module support 3 years ago? Theo may be ... peculiar ... but no-one can call him completely irrational without revealing themselves to be even moreso.
They are bugs, but there are particular kind of bug that allow bad people to do bad things to your computer or your data. There's a huge difference between a graph displaying text in the wrong sized font and a bad guy being able to steal your spreadsheet with all of your company's confidential data.
We made the OOM killer smarter a few years ago.
Anybody who chooses Solaris over Linux based on memory allocation policy is simply uninformed. If you set vm.overcommit_memory = 2, Linux will behave just like Solaris in this respect, except a tad safer. Linux is a tad smarter about memory allocation, whereas Solaris is very - uhm, "straightforward" (aka dumb).
With Linux you can ALSO choose other options, depending on the workload, and can tune the exact percentages to best fit your workload. Solaris provides no such options. It does exactly what it does and that's it, the admin has no say in the matter. Programs just get fatal errors and crash, with no option to make appropriate use of swap etc.