The only reason this isn't worth a freakout is that nobody running Linux in a graphical desktop configuration could ever have assumed that the machine was multiuser-safe to begin with. The reality is probably that no Linux (or FreeBSD) system in any configuration is secure from an attacker that can run native code in an unprivileged process. But with X11 running, you never had a chance.
I'm always amused by the dismissive tone programmers take to findings like this --- "oh, any thoughtful C programmer could avoid these problems". No, they can't. How many billions of dollars does it take to prove this point? The very best secure programmers in the world, building C (and C++) codebases from scratch specifically to address these problems, almost invariably fail to do so: memory corruption bugs get found in these systems just like they do in '90s-vintage X11 code.
C is my very favorite language and I'm not saying people shouldn't use it (well... they should avoid it, actually), but people should work in it with their eyes open.
At no time has there ever been a Linux kernel release with no local root exploits. There have been periods of uncertainty when we didn't know the exact exploit but we always find out eventually. Keep this in mind whenever you think about Linux security.
That said, Linux users do have an unwarranted confidence in the security of the operating system. The kernel developers actually don't care that much about security--but because it was designed with some level of sanity, most installations are headless, and the non-headless installations aren't used by very many people, it has been able to tout some apparently obvious superiority to e.g. Windows (which isn't really the case post-Vista, when Microsoft had enough of being a punching bag.) Same thing goes for Mac--a whole lot of confidence, but not a lot to back it up. Curiously, a lot more Mac malware has shown up after they gained considerable market share.
There is no security in this world, only opportunity.
Careful. I'm not making a "Linux vs. Windows" argument here. I'm making a Linux desktop vs. any other computing environment argument. Not all computing environments are equally exposed to attacks. It is for instance much more annoying to exploit iOS vulnerabilities than it is to pivot from user "nobody" to root on an Ubuntu desktop system.
That these two environments aren't comparable --- one is a heavily-locked down and simplified computing environment and one is a general purpose desktop operating system --- is exactly my point.
I totally agree. It wouldn't be fair to compare Ubuntu to Chrome OS either. (My response was aimed more at thrownaway2424's comment, and I didn't mean to give the impression that everything is equally vulnerable, just that most software has exploitable bugs that may or may not be known.)
Did I say avoid the problems? I'm pretty sure I said that the problems are not surprising. And, to add to that: I think it's especially not surprising in an older code base from an era in which this was less common knowledge. New code bases are of course not infallible but awareness of this is a higher priority than it used to be.
I think it's also interesting that issues like this sometimes remain in libraries because people think the caller should figure out overflow. From a casual read of the announcement it looks like they took a better approach in some areas, i.e. the library assumes the worst of the caller. I'm reminded of something I read a few years back about the OpenBSD folks adding more overflow checks to calloc which does multiplication. It's nice when you can catch it in a library rather than pushing decisions to the caller.
> C is my very favorite language and I'm not saying people shouldn't use it (well... they should avoid it, actually),
Could you elaborate on this? Particularly "you should avoid it, but I'm not saying you shouldn't use it" (what exactly do you mean?), although I'm also curious why it's your favorite. This is coming from someone who is spending more and more time with C, so genuinely interested.
The reality is probably that no Linux (or FreeBSD) system in any configuration is secure from an attacker that can run native code in an unprivileged process.
There's a lot of web hosting companies which use Linux on their servers?. Are you saying they're all doing it wrong? Or by "an unprivileged process" do you mean "not specifically sandboxed process"?
A thoughtful programmer can avoid these problems by using proper process separation. For example, openSSH works this way. In this setup, compromising the untrusted part of the application does not give you full control. If you can keep the trusted part small, you can avoid a lot of problems.
X11 violates this principle big-time. Basically, it's a giant application that runs entirely as root. For most of its lifetime on Linux, it included a huge chunk of what we would normally expect to be video driver code that lives in the kernel. It's always had a lot of trivial denial-of-service attacks, keystroke grabbing attacks, and so on.
X11 was a great system, especially for the time, but let's not pretend that it was "the very best secure programmers in the world, building C (and C++) codebases from scratch... specifically for security." We are building better systems, like Wayland, the Android stack, and so on, and it's not taking "billions of dollars." Maybe millions.
Developers are much more security aware these days. Wayland will not require root privileges which means a buffer overflow isn't as critical. It also will not be network transparent which reduces the attack surface enormously. Then remember it was created because xorg had accumulated so much cruft over the years because of its obligation to support dozens of outdated X11 extensions nothing (except for emacs :)) uses. Hopefully that means Wayland's devs will keep it lean and clean and easy to secure.
(1) Developers tend to be more aware of secure programming issues than they were in the 1990s, when you could coerce a shell out of a lot of SUID programs and network daemons with a well-placed pipe filter or semicolon character. But that doesn't make them better at implementing more securely. Case in point: Nginx, a codebase that was designed from the start for modern C secure programming, had an integer overflow just a couple days ago; a couple years back, our team found another serious Nginx bug (that time, an info leak) stemming from their attempts to be extra-cautious. So simply being aware of secure programming issues isn't an assurance that code is actually more secure.
(2) More importantly: it doesn't matter so much if there are fewer memory corruption vulnerabilities in C programs. Like I said before: what matters is if there are any of them, or at least any that can be discovered in a reasonable amount of time. In (say) C# or Java serverside code that doesn't call out to C code, we can say with some assurance that there aren't any such flaws; we don't have to stare at the same 10,000 lines of code for a month to prove that to ourselves. You simply can't say that about C codebases. There could be a memory corruption flaw in Dovecot right now, or in Postfix, or (less likely, but still...) tinydns.
Well, we're going to have to agree to disagree. I do think security has improved since the 1990s. I think that this kind of "we're all doomed, it doesn't matter what you know" attitude that you are displaying is exactly the problem. It does matter what you know and how you architect the system. Security has improved a lot, even on platforms like Windows that are heavily C/C++ based.
Garbage collected languages are nice, but they're really just an extension of the general principle of minimizing the trusted code base. They are not a silver bullet (witness the recent Java, Ruby, etc exploits). I am all in favor of these languages, and especially Golang, which shows a lot of promise.
What I'm not in favor of is using a really crappy program written in language X as a stick to beat the language designers with, regardless of what value of X we're talking about.
I gave specific examples of modern C codebases for which lots of attention had been paid to security that subsequently suffered vulnerabilities stemming from memory corruption. You respond with "garbage collected languages are nice but they're really just an extension of the general principle of minimizing the trusted codebase", which is nonresponsive to my point. We agree: we disagree.
I don't think it's negligent to write things in C. I like C, a lot; it's my first language. But stop kidding yourself that with just a couple modern development practices you'll produce code in C that is comparably secure to Python or serverside Java. You won't.
I'm really annoyed by your refusal to stay on topic. I pointed out a specific problem with security in many higher level languages-- the presence of eval and eval-like constructs in the language. You changed the topic. I pointed out that minimizing the size of the trusted code base, and reducing the privileges with which code runs is the foundation of any successful attempt to make secure coding easier. You changed the topic.
I'm really tired of the ideology that everything written in C is insecure, and everything written in higher-level languages smells like roses. Should we be surprised that things like Wordpress, Ruby on Rails, and even client-side Java are riddled with security vulnerabilities? Well, when programmers refuse to learn from the mistakes of the past, and think using a higher-level language is a magic elixir for achieving security, it's not a surprise.
I'm always amused by the dismissive tone programmers take to findings like this --- "oh, any thoughtful C programmer could avoid these problems". No, they can't. How many billions of dollars does it take to prove this point? The very best secure programmers in the world, building C (and C++) codebases from scratch specifically to address these problems, almost invariably fail to do so: memory corruption bugs get found in these systems just like they do in '90s-vintage X11 code.
C is my very favorite language and I'm not saying people shouldn't use it (well... they should avoid it, actually), but people should work in it with their eyes open.