Linux... too many security vulnerabilities for comfort?

[bascule]

Is anyone else disturbed by the number of system level compromises the Linux kernel has seen in recent history?

We have the newly discovered mremap() vulnerability (as seen on /. et al), the brk() vulnerability from a little more than a month ago, and the ptrace vulnerability from last March (which is the second ptrace() vulnerability in recent history)

That's three system level compromises in the kernel alone within a period of a year, in a system which is supposedly seeing the same degree of regression testing as commercial Unix systems. Comparitively, Solaris has had not had a kernel vulnerability resulting in a system level compromise in over a year.

Now granted, OpenBSD, reknowned for its security, saw itself afflicted with a local root vulnerability due to a race condition which was very similar to the ptrace() vulnerability on Linux. But with buffer overflow issues in system calls, isn't it time some of these companies that are staking their future on Linux, such as IBM, SGI, and Novell, pay to have the code implementing the entire Linux system call table thoroughly audited? It seems ludicrous that we are seeing buffer overflows in the system calls of an operating system that's over a decade mature.

[octalpus]

Which bothers you more... vulnerabilities that have patches released, usually within days or even hours of their discovery, or vulnerabilities that are swept under the carpet and ignored because the great satan doesn't want anyone but its own developers touching its code?

[jesse]

to play devil's advocate,

what about vulnerabilities that are resultant from the source code being freely available to anyone, resulting in more opportunities for discovering buffer overflows and race conditions by easier reverse engineering?

(not that i care about the OSS/closed debate, but that argument can cut both ways)

[bascule]

Which bothers you more... vulnerabilities that have patches released, usually within days or even hours of their discovery, or vulnerabilities that are swept under the carpet and ignored because the great satan doesn't want anyone but its own developers touching its code?

The problem with this argument is that a similar patch was not made available for the Linux 2.6 kernel because the kernel developers were unable to forumlate an attack vector which would lead to a system level compromise. However, mremap() may still be used to corrupt the Linux 2.6 VM space.

[sysctl]

what about vulnerabilities that are resultant from the source code being freely available to anyone, resulting in more opportunities for discovering buffer overflows and race conditions by easier reverse engineering?

well first of all, code auditing and reverse engineering are two entirely different beasts (which i will defer from going into). you do bring up a valid point though; but i have to ask you this: is security through obscurity really security at all?

...and my opinions on linux as a whole are less than favorable.....

[highwizard]

Ever herd the term "To late for that now". I rather have something that doesn't have it hardly ever. Why would you even say that comment in the first place. I rather not spend my time securing my box 24-7, I have other things to do than that. Most people don't have a network admin monitoring the system 24-7. But even then, it might be to late. It only has to happen once before you realize there is a vuln and you get the patch ect.

As for great satan. I think it's fine that he doesn't allow anyone to touch the code. That's called "Control". Knowing everything is in it's place and knowing where to look for something. Not to mention having nimrods looking at it making more VULNS to it. That to me is more secure. That's why I still stick with it. Even though it has it's vulns, it's alot harder to come by than actually seeing the code on a day to day basis. But I guess that is blinded for the fact of image, speed, free and other great things that makes up linux. Did I mention Image?

:)

First off, if you are refering to Bill Gates he is not satan around here... Chris has the title safely under wraps. Secondly, I am not quite sure as to what you are saying, but I am guessing "since MS is closed source there are less vulnerabilities then open source" sorry I used proper spelling (couldn't be EXACTLY like you). If that's what you meant to say, then you are dumb. I don't dislike you because you can't spell. I dislike you because you make those people around you dumber.

[bascule]

you do bring up a valid point though; but i have to ask you this: is security through obscurity really security at all?

To a certain degree yes... without source code it's very hard to formulate complex attack vectors when a vulnerability is discovered. In the case of the mremap() vulnerability, the attack vector relied on complex manipulation of the VM which required intimate knowledge of its implementation (the proof-of-concept exploit was written by the kernel developers themselves) Attempting to derive such an exploit through analysis of the resultant VM opcodes alone would be an almost insurmountably difficult challenge.

[Mr. Peabody]

Which bothers you more... vulnerabilities that have patches released, usually within days or even hours of their discovery, or vulnerabilities that are swept under the carpet and ignored because the great satan doesn't want anyone but its own developers touching its code?

Many exploits are discovered and exploited for quite some time before being recognized by CERT.

[bascule]

It appears FreeBSD has seen three system level compromises in system call implementations in the past year as well, although one is FreeBSD 5.x specific:

ftp://ftp.freebsd.org/pub/FreeBSD/CE...4:02.shmat.asc
ftp://ftp.freebsd.org/pub/FreeBSD/CE...:09.signal.asc
http://www.pine.nl/press/pine-cert-20030901.txt

Not a good year to be running a shell server on top of free operating systems, that's for sure...

[Mr. Peabody]

Comparitively, Solaris has had not had a kernel vulnerability resulting in a system level compromise in over a year.

I thought you read this post. Did you miss this link that reveals a kernel exploit discovered last month that addresses vulnerable version Solaris 7, 8, and 9? Maybe you should check here for some information on sun security issues. Everyone is getting exploited. The millions of new lines of code that went into the playing field this year has obiviously seen some bugs. Technology evolves, these are all just steps in the process.

[bascule]

Did you miss this link that reveals a kernel exploit discovered last month that addresses vulnerable version Solaris 7, 8, and 9?

Congratulations, you've just proved I'm not psychic... did you check the date of that post and compare it to the date of the vulnerability you linked?

Maybe you should check here for some information on sun security issues.

Maybe I should read Sunsolve once in awhile... apparently in your perception of reality I don't do that in my day to day life as a certified Solaris administrator. Next you'll be telling me to read BigAdmin...

Just how old are you, and what is your job? Are you a Solaris administrator? Are you Solaris certified? Do you have over three years industry experience administrating Solaris? Ever analyze a Solaris core file to determine which hardware in a system is bad? Ever analyzed hardware problems through Forth in OpenBoot?

If not, perhaps you should try to be less condescending when talking to those who are...

[Floydr47]

Which bothers you more... vulnerabilities that have patches released, usually within days or even hours of their discovery, or vulnerabilities that are swept under the carpet and ignored because the great satan doesn't want anyone but its own developers touching its code?

There is something that I have been curious about, ever since first hearing of Linux, Unix and other OS with open source code. Wouldn't an OS that is "source code controlled" be less likely to vulnerabilities then a source code that is "open" to anyone who wishes to tinker with it? I am not knocking open source, but where is security if everyone is allowed access to the source?

[simple3]

There is something that I have been curious about, ever since first hearing of Linux, Unix and other OS with open source code. Wouldn't an OS that is "source code controlled" be less likely to vulnerabilities then a source code that is "open" to anyone who wishes to tinker with it? I am not knocking open source, but where is security if everyone is allowed access to the source?

the vulnerabilities are just as likely. what may differ is how likely people are to find them. the problem is that either way, the people most likely to find vulnerabilities are the people looking for them. in a closed source environment one could not fix even a known vulnerability. i am sure someone else can go into this further. the arguments on both sides of this debate are plentiful and you can easily google for them.

--simple3

[skroo]

This is getting old; the rash of recent kernel issues reminds me of the string of openssh vulnerabilities from mid-2002. From http://www.securityfocus.com/archive...5/2004-02-21/0 , we now have a second mremap() vulnerability, which means another kernel re-roll if you don't want local users exploiting it. w00t.

[bascule]

we now have a second mremap() vulnerability, which means another kernel re-roll if you don't want local users exploiting it. w00t.

Yes, and this has a known attack vector for 2.6 series kernels. Thank god I can trust my users... I'd hate to be running a Linux-powered shell server used by total strangers.

Meanwhile Sourceforge's shell servers are running this kernel on their shell servers: Linux sc8-pr-shell1.sourceforge.net 2.4.20-30.9bigmem #1 SMP Wed Feb 4 20:27:00 EST 2004 i686 i686 i386 GNU/Linux

...which is, of course, vulnerable to the three system level compromises I linked in my original post.

Did I mention that all their shell servers have read/write NFS access to their central fileserver?

Sourceforge certainly has dubious security practices...