A few days ago, the following exploit was published: http://blog.zx2c4.com/749
Another small step in debunking the myth of linux security. What is also interesting is that this bug was introduced only recently:
In 2.6.39, the protections against unauthorized access to /proc/pid/mem were deemed sufficient, and so the prior #ifdef that prevented write support for writing to arbitrary process memory was removed.
Well, those linux kernel developers sure are geniuses when it comes to writing secure code, aren’t they? And all those eyes that are allegedly inspecting the source code all the time… well, this code was submitted in March 2011. So it took many months to find the bug, and it is now widespread. A fix is available now, but there will obviously be tons of unpatched systems out there (people with a false sense of security… after all, they’re running linux, right?)
Another interesting tidbit is this:
It turns out that su on the vast majority of distros is not compiled with PIE, disabling ASLR for the .text section of the binary!
Yes, really! Which is interesting actually. I recall when I ported some of my CPUInfo code to OS X, that I ran into a problem. It did not allow me to use the EBX register freely. This was because the default build options in OS X are to compile everything position-independent. That is probably related to this: position-independent code enables Address Space Layout Randomization (ASLR). I didn’t have the problem on linux, because I used Ubuntu, which is one of the many distros that does not force PIC. As an aside, Windows relocates code in a slightly different way. Windows calculates the addresses with the PE loader, and patches them into memory. This takes slightly more time during loading of an executable, but it saves time during execution. An interesting difference in tradeoffs between Windows and linux. And as a bonus, Windows binaries don’t need to be compiled with any specific flags for ASLR to work.
So, a few minus points for linux security again: both in the quality of the kernel code, and in the quality of the default configuration of most linux distros.
Scali's OpenBlog™ 
Pingback: The myth of linux/open source security | Scali's OpenBlog™
You’re talking about individual Linux distros. Even if by default Windows has more programs that run with ASLR, you can compile programs manually (or through a package manager like Portage) in Linux, which you aren’t allowed to do on closed source OSes. The same applies to the various *BSDs, etc. Plus, you have the grsecurity patch available which can significantly harden it’s ASLR implementation, among other things.
Disclaimer: I am not a raving Linux fanboy. I left Windows because I was always fighting with lower level customizations which I found to be much easier and intuitive in Linux. The reason I use Linux specifically is just because it has good hardware support, a large collection of programs available, and I can configure it to be much more secure. I understand the situations in which Windows beats Linux (e.g. your other blog post on dynamic boosting of thread priority in active windows in Windows. IIRC, KDE does the same thing to an extent, and cgroups can help. I do wish Linux has a decent implementation of that… oh what’s it called, that thing where very low or very high priority processes are “shaken” a bit to prevent the paradoxical sluggishness of some extremely high priority processes). What I don’t like is your over-generalization and your ignoring of the fact that you *can* improve Linux’s security to be far beyond that of Windows. In many cases, even “out of the box” distros like Debian are more secure on many levels (you don’t have to mention the openssl weak keys bug).
Overall, I like the security of Linux, but I do hate Linus’ (and many kernel devs’) mantra of “a bug is a bug” where they refuse to point out what commits fix some nasty security issues, but the mere fact that you can patch the kernel to be much more secure, whether by grsecurity/PaX or RSBAC (which I recently found out also has a large amount of hardening features, not just a MAC).
On a similar note, I just want to mention I’m very tired of ignorant Linux fanboys as well. Just recently I was arguing about the quality of the Windows display engine vs Xorg, and he said something along the lines of “I prefer my network transparency thankyouverymuch”. He had no idea that Xorg didn’t have true network transparency for a very long time… On the topic of X servers, I am optimistic about Wayland. Hopefully it will do a good job at replacing this 20 year old hunk that even has left over code from when it tried to act as the printer manager.
Well, bottom line is still that on linux, various BSD’s and OS X, whether or not ASLR works, depends on how the program is compiled. On Windows it doesn’t.
So it will always be a problem. If you install a binary distro out-of-the-box, you can’t be sure that ASLR works properly, as you can see. Same with closed-source applications obviously. With open-source applications, at least you can recompile them… but it will still be difficult to check every single program (you’d have to make sure that there are no custom compiler flags in the makefile, which may turn ASLR off anyway, even if you recompile it).
It’s just an imperfect implementation of ASLR. It depends on something it shouldn’t depend on.
That’s because I don’t see that as a fact at all. Problem is just that most people don’t even know what kind of security features Windows has, or how well they are implemented. I mean, take this particular case for example: most people see ASLR as a ‘tickbox’ feature. “Oh, Windows has it, *tick*, linux has it as well, *tick*”. This blog points out that there’s a bit more to it than that.