Developers of the Linux kernel created a security mailing list this week to air future vulnerability information regarding the open-source operating system’s core code.
Linux developers create forum to air core flaws
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
This is a good move.
/me gives thumbs up. 🙂
It sounds like a good idea if it’s used.
Now they need an RSS feed to go along with my BugTRAQ feed in my firefox.
There are already a handful of linux mailing lists, security mailing lists, and linux security mailing lists. This list will do little good, plus attract more spam and other nonsense to the list.
Well… maybe you’d like read the views of the people who think this is needed. Previous discussion available here: http://kerneltrap.org/node/4540
isn’t any os written in C or c++ going to have security issuses? Buffer overflows.
Anyone care to answer?
Not just that, but integer overflows, uncleaned buffers being passed to userspace containing sensative info, privledge escalation, and those are just a few. No Language is 100% secure, even those scripting languages have their issues (NeverEverNoSanity worm anyone?). Also no real OS is written in C++.
Many “real” OSes are written in C++.
Java and .NET and every other language ever invented are fundementally flawable from a security perspective.
Security is not about language choice. It is about architecture and flawless implementation.
I think Linux really needed this. I hope we will see some good progress of this in the future.
Keep the good work up!
Mostly out of curiosity.
I can distincly remember Linus flaming someone for writning a kernel module in C++ and arguing for that OOP was just stupid in kernel programming.
What OSes are written in C++, and how do they get affected by what Linus is talking about?
So do I. Linux has had so many security issues lately that it’s definitely needed to start focusing on security. I want it to get to the level of security as the BSDs are so that I feel safe when using Linux…
You can write perfectly safe C++ code easily. Just don’t use the old C compatibility features (like pointers and char arrays). Don’t blame C++.
If you view security as a process, the BSD’s seem to have the better process regarding security.
Nevertheless, having many security issues lately IS a sign of activity in the security sector.
Whenever a new type of exploit is found all kinds of software gets checked for these types of flaws. This leads to security warnings coming in waves. So do not underestimate the security aspect of an operating system but also do not unnecessarily panic. The really uncomfortable situation where a flaw was detected by an evil cracker first has not yet occured as to my knowledge. All other flaws are controllable by patching, patching and patching your systems. apt-get is your freind
You can write perfectly safe C++ code easily. Just don’t use the old C compatibility features (like pointers and char arrays). Don’t blame C++.
I second that. 90% of C security vulnerabilities are errors in string handling or buffer overflows.
The buffer overflows are fairly stupid. I can’t really understand how so many exist. Both are solved in C++ by the use of std::vector and std::string (or equivalents).
Some situations still required the use of pointers, but it is often easy to encapsulate this in a class with no user-visible pointers.
Someone should write a ‘C+’ that is C99 + intuitive string handling + resizable arrays. Then there’s at least a chance that the “OOP SUCKS!” people would use a language with less error prone string/array handing.
Dude, buffer over/under flows are an issue with lazy app developers, but not really in the kernel. There the majority of bugs are much more subtle. And yes they could be fixed by deoptimizing everything and generalizing. But that would kill performance. So as always, we’re making a tradeoff of the occasional security bug for kickin performance. You could write a “correct” kernel, but then it would be so slow no one would use it.
Buffer overflows aren’t exactly hard to fix even in C. It’s not hard to write your own stringbuffer/vector implementation anyway, or use someone elses (GLib is good, http://developer.gnome.org/doc/API/2.0/glib/index.html)
“You can write perfectly safe C++ code easily. Just don’t use the old C compatibility features (like pointers and char arrays). Don’t blame C++.”
Hahaha. Pointers are C legacy? They are a core part of the language. Nothing is inherently insecure about pointers. Maybe new programmers don’t realize that all objects in Java are really pointers.
“Buffer overflows aren’t exactly hard to fix even in C. It’s not hard to write your own stringbuffer/vector implementation anyway, or use someone elses (GLib is good, http://developer.gnome.org/doc/API/2.0/glib/index.html)”
Good Call. I choose to write my own string class though
Further, buffer overflows are not an issue on AMD64 when the proper support in the OS. I don’t remember the acronym, it is basically hardware buffer overflow protection
As for writing an OS in C++, I did it. My boot-loader was Assembly, my drivers were C, and my Kernel was C++; it worked fine for me.
-VoidLogic
Yeah, normal buffer overflows (like old gets() examples or strcpy) probably aren’t a big issue here as you’re not taking a lot of user input, like most applications. Never-the-less, there are bugs.
I think the real gain of this mailing list is giving the developpers a chance to react before an exploit is necessarily publicized. Of course that will depend on who discovers the exploit and how they handle it.
-b
Well, the recent security issues in the kernel included:
-using untrusted user data to calculate an array index. This is a buffer overflow, but a non-obvious one.
-not checking that an executable doesn’t request overlapping virtual memory addressess allocations. This class of bugs exists due to the basic design of how modern computers handle memory.
-race condition, where two threads running on different CPU’s requesting stack expansion simultaneously could give one of them access to a third process’s memory. This class of bugs is due to incorrectly used threads – and any language / system, Java, C, C++, anything, is quite vulnerable to this type of bug.
-timing bug, where processes started before the LSM module is inserted receive root capabilities. This is due to the kernel developers transitioning from an old-style Unix security system to a modern capabilities security system, and messing up what happens when a process is started in the old style system but continues executing in the new style system. This sort of thing happens with any project when you radically change its internal architecture.
So no, most kernel bugs are not buffer overflows, and even the buffer overflow bugs are quite subtle.