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.
If they're not a bug it implies they're intentional.
I can't think of many developers who intentionally build in security problems.
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 is a problem I just don't want to work on."
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.
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.
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.
If kernel security problems were "just bugs", then go ahead and disable address space layout randomization. The system will be as stable as before (maybe even more stable). Surely disabling ASLR won't introduce bugs, however it certainly will introduce a security problem.
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.
When you have multiple people looking at the same code and making numerous changes, bugs are inevitable in open source code.
Source: "Rebel Code: Linux and the Open Source Revolution" by Glyn Moody
For example: The order in which certain parts are done in a program can also be used to exploit certain feature, or the way things are stored can expose things even certain hardware or OS feature.
Testing is the only tool most people use but there is also a lot of knowledge about this, there are guides specifically about security in certain languages, for example: https://www.cert.org/secure-coding/publications/books/secure-coding-c-c-second-edition.cfm
Something sounds a little off about that one.
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.
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 disrupted the dinosaurs of the IBM era.
But in the same way the IBM PC became irrelevant in the 90's, so Linus has become irrelevant now.
Yes, half the world's infrastructure is built on linux, but taking Linus seriously on an issue like security is like caring about wheel manufacturers' opinions on using generative AI networks to optimize traffic flow.
No Mr. Linux, I'm sorry but there are several documented software engineering practices that can be exploited by malicious hackers to gain control of a system ("client side authentication" is just an example), but neither of these practices are "software bugs".
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)
And finally there's the "didn't hit Preview before Submit" bugs.
If they're just bugs, then there's always a technical solution, and a perfect technical solution at that. Why haven't you fixed all the bugs Linus? Spearfishing is a bug? Physical security is a bug?
I'm just overjoyed to see someone from Team Hubris get their ass handed to them in such eloquent style.
LOL@vword: crashed
My kindergarten teacher told me its not nice to have a Potty mouth especially if you're a big boy.
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.
...are just bugs, that require the highest attention.
No preview on mobile. :(
but... the performance issue. Micro v. Mono is so often argued on /. you can make a drinking game out of it. But the conclusion always comes down to poor (read: non-workable) performance on a pure micro-kernel. OTOH, hardware keeps getting better, perhaps with real breakthroughs on the horizon, and maybe an architecture could come along that's more suitable to a micro-kernel. Could the day of the practical micro-kernel come some day? or will it always be just a distracting off-topic discussion that stalls once performance is seriously considered?
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.
In the full context, I think he has a point; he was arguing against panicking the kernel when an out-of-spec situation is found. The security guy's (Kees) patch presumed that out-of-spec indicated an attack, when it most likely just indicates a bug. Being a security guy myself, I sympathize with Kees, we tend to think about things in terms of how to mitigate possible attacks, and reducing pwnage to DoS is a good thing. Not so much, though, if the panic gets triggered a lot by ordinary bugs. In that case, we need to detect the problems, but continuing to run is good.
The BSD folks have already gone through this. You cannot always know ahead of time which bugs will lead to security problems.
OpenBSD's thinking:
Our security auditing team typically has between six and twelve members who continue to search for and fix new security holes. We have been auditing since the summer of 1996. The process we follow to increase security is simply a comprehensive file-by-file analysis of every critical software component. We are not so much looking for security holes, as we are looking for basic software bugs, and if years later someone discovers the problem used to be a security issue, and we fixed it because it was just a bug, well, all the better.
* https://www.openbsd.org/security.html
In the FreeBSD 4/5 time frame a whole bunch of ASSERTs were added to the kernel, which caused many panics and thus much annoyance. But this forced the developers to look at each panic and often caused a code clean up which in turn helped long-term stability. Even now there are a bunch of #defines enabled in FreeBSD during development that are removed when a release is tagged.
Perhaps there should be a DASSERT (debug-ASSERT) that can be enabled during development, and that is then disabled for production releases. This allows devs to experience pain and help to fix things, but will less likely to hurt actual production systems. If you enable the (compile-time? runtime sysctl) option, DASSERT maps to ASSERT, otherwise to maps to a NOP or a kprintf.
So long as Linus is in charge Linux will be the laughing stock of the security world. Linus is a decent enough programmer, but he doesn't understand security and has hurt his own project immesurably to the point where many of us in the security research community have dumped it and run Windows on our laptops and BSD on our servers.
Most effective security threat. Not a bug.
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."
Some security problems are just features. Shut the fuck up Linus. Nobody cares for your worthless opinions
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.
Seems like this applies to everything. If a lock is broken then the bug is that the lock isn't strong enough. If the encryption is broken then the encryption isn't strong enough so bug. What about using an F bomb when talking...is that a bug in your thought pattern?
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.
Yes but languages like C make bugs really easy to make. I would say that most bugs (but not all) could be avoided by simply having a better language (like Rust or Haskell) for example.
Well, if poor designs are bugs, then yes.
There are two different classes of bug that apply to systemD, namely design-time bugs and implementation bugs.
The primary fault is a design bug, in that no complex system should ever be placed in PID 1. That's a fault that would have eliminated the systemD architecture from consideration early on, if the primary systemD developer and advocate had been a rational engineer who works off pro/con lists. But he's not an engineer unfortunately, but more like an ego-tripping hacker with an elevated opinion of his own infallibility.
No complex system can be without bugs and so systemD is inevitably full of them, many latent until identified and fixed, but even fixes introduce new bugs. As systemD gets more and more complex, this situation just gets worse, not better. And PID 1 is exposed to this mess, because of the initial design-time bug.
Still sounds like a great patch to put in a research kernel, as it identifies bugs.
Equifax security was complete crap. They weren't using any best practices. They started when security wasn't a large concern and never evolved their systems to modern standards. It was only a matter of time for them.
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.
linus was bought by big corporations long time ago, he's just a very useful moron
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.
I'll buy into that.
"....Somebody wanted to add "security" code that would kill of a process,..."
Linux already kills processes randomly. Here is how it works. Say you have 4GB RAM. Now the user starts 10 programs that in total reserve 10 GB RAM. That is ok as Linux happily overallocates RAM. As the 10 programs slowly use more and more RAM, the 4GB will get full. As soon as more than 4GB RAM has been used, Linux will start to kill processes randomly. Yes it is true and one of the reasons why Linux is considered unstable by Mainframe/Unix sysadmins.
For instance, Solaris does not overallocate RAM. The user is not allowed to start programs that use more than 4GB RAM in total. Solaris does not need to kill processes randomly.
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.