Linux/Unix Tops Charts for Vulnerabilities in 2005

BeanBunny writes "I realize that this topic is almost as volatile around here as Intelligent Design, but I think this is interesting nonetheless. US-CERT has released their year-end vulnerability summary. According to InformationWeek.com, Linux/Unix (including Mac OS) had almost three times the number of OS-specific vulnerabilities reported last year compared to Microsoft Windows. Obviously, statistics are meaningless without the proper conjecture, speculation, and opinionation, so let the debate begin again over which OS is really more secure."

Comments

Re:Another Take

[dch24]

Of course Microsoft isn't going to admit to vulnerabilities if they can fix them quickly and quietly. But how will Microsoft know their vulnerabilities exist? We all have a (well justified) gut feeling that there are vulnerabilities in Microsoft's products, based on what has been discovered thus far, but the closed-source method of developing means there are vulnerabilities which likely will never be found. Look at the severity of the vulnerabilities too. Most of Microsoft's vulnerabilities are high to critical severity because of a deeply ingrained Windows culture which has numerous security nightmares, from browsers to privilege levels to file permissions.

The *nix vulnerabilities listed are more numerous because there are more programs for *nix, more kernel-level and library developers for *nix, and generally more eyes looking at the code. However, the high and critical severity vulnerabilities are extremely rare, for these same reasons. And also, because the *nix users are miles and miles ahead of Windows users in being aware of the security issues that affect what they are doing.

Re:One Take

[Anonymous Coward]

Brian Krebs is clearly either extremely stupid, or has an axe to grind. If you look at the Cert Cyber Security Bulletin 2005 Summary [us-cert.gov], you can see that many of the lines in it end in "(Updated)" A simple count of lines gives the results that Brian quotes, however there are far more "(Updated)" entries in the Unix/ Linux Operating Systems section. Removing these lines gives the following results:
including excluding
"(Updated)" "(Updated)"
Windows 813 671
U/L 2328 891
Multiple 2057 1512

(sorry about the spacing - can't find any way of doing it)

greatly reducing the proportion of Unix/Linux vulnerabilities

by alanw (1822) * Alter Relationship on Saturday December 31, @08:32AM (#14370036)

"OS Vulnerability" vs "Application Vulnerability"

[javaxman]

There are more than one problem here, but something which must not be ignored is that a large number of the listed 'vulnerabilities' are very application-specific.

Want one example? The CM Cyrus IMAP server sure as heck isn't installed on my Mac OS X system, and I doubt I'd ever install it. I don't think I'd install it on my Linux box, either. If I did install it, and there was a bug in it, I sure as hell wouldn't consider that bug an "OS" problem, would you ?

And I'd be willing to make the same distinction for Microsoft, as well, at least so long as the application error isn't in a default-installed DLL or in an always-installed application, like... oh, Internet Explorer, for example. I'm not so sure I should fault Windows because the Eternal Lines web server has some sort of issue. There's the OS, then there are the apps that run on top of the OS.

So really, the counting and analysis are so broken that it's hard to even discuss. Call me back when individual distros and specific OS kernel builds are broken out into separate counts. Call me back when non-default-installed or at least not-commonly-used applications are broken out ( i.e. I'll give you web servers and browsers normally used with any platform as part of the OS ), but I don't think Linux in general is less secure because Joe's Custom Server has a bug in it. I'd like to see some *useful* summary of this information, please...

Here's a quick answer:

[khasim]

TFA says that there were 2,328 reported vulnerabilities for *nix.

I counted the lines and there are 2,329 lines.

Here's an example of 10 of them:
# BZip2 File Permission Modification
# BZip2 File Permission Modification (Updated)
# BZip2 File Permission Modification (Updated)
# BZip2 File Permission Modification (Updated)
# BZip2 File Permission Modification (Updated)
# BZip2 File Permission Modification (Updated)
# BZip2 File Permission Modification (Updated)
# BZip2 File Permission Modification (Updated)
# BZip2 File Permission Modification (Updated)
# BZip2 File Permission Modification (Updated)

Yep. BZip2 is listed 10 times, but the reference to each of them reads the same:

A vulnerability has been reported when an archive is extracted into a world or group writeable directory, which could let a malicious user modify file permissions of target files.

And then they list 10 different distributions. Hmmmmm ..... it looks like the old "multiple reporting" problem.

So, one problem in BZip2 == 10 counts of "problems".

Re:Here's a quick answer:

[OdieWan]

Removing the duplicate lines is enlightening;
cat usoft.txt| sed -e 's/(U|updated)//g' | sort | uniq | wc
    747 lines
cat unix.txt| sed -e 's/ *(Updated) *//g' | sort | uniq | wc
    1050 lines

That brings them almost in line with each other. Of course, we could do a half-assed job of cutting things down to just the OS to remove concerns about all the bundled apps;

cat usoft.txt| grep Microsoft | sed -e 's/(U|updated)//g' | sort | uniq | wc
    160 lines
cat unix.txt| egrep '((K|k)ernel)|(GNU)|(XFree86)' | sed -e 's/ *(Updated) *//g' | sort | uniq | wc # GNU/Linux, not Linux!
    167 lines

Of course, any of this would be far too much work for the author of the article.

Re:Vulns you won't see listed

[jguthrie]

On my computers, /dev/hda is owned by root.disk with permissions of 660, and none of these computers has any real users in the disk group. So, it doesn't matter if I try it at home or not, it's not going to do anything. I suppose that if I routinely ran as root, it would be different, but I don't and it's not.

Re:One Take

[LordNightwalker]

Not only that; the comparison is Linux/Unix including MacOS... How many kernels are we talking about here? There's the Linux kernel, 3 different BSD kernels, the MacOS kernel based on BSD (I assume it's different enough to count as a separate kernel, don't really know), HP-UX, AIX, SCO Unixware, Solaris (just check the vulnerability list) and probably some other Unix variants I forgot to mention compared against one OS. Yeah, sure, there's different Windows versions out there, but all Windows XP "distros" are based on the same kernel, with some "advanced" features compiled out of configed out...

Even assuming they're not just counting Windows XP vulnerabilities, but also the ones found some of the other Windows versions that are still in use, it's still a shitload of unix variants compared to a small amount of Windows versions. Fair comparison indeed. Doing statistics like this could even make the Ford Pinto look safe. After all, the number of deadly incidents involving a Ford Pinto pales in comparison to the number of accidents involving all other brands and models if you add them up.

Other than that, just look at the damn report... Most bugs aren't even OS bugs, but bugs in third party software. How the hell is a bug in Acrobat Reader, 3Com 3CDaemon, F-Secure Antivirus or Platinum FTP Server MS's fault? If you look at it like that, of course you're gonna find a lot more bugs in the linux/unix category: there's simply a lot more software for those OS's. Your average Linux distro has more unique applications on board than most people would ever install on a Windows box, and a lot of it is indeed of dubious quality because it simply wasn't written with security in mind. Just like all that shareware crap for Windows.

I don't question the validity of the report, but I do question the journalistic integrity of the people reporting this. This is a list of application vulnerabilities broken down per OS, where OS is one of the following: "Windows" and "Other"; not some measure of the security of the OS's in question. Heck, lots of stuff on the Windows list is dubious software I wouldn't wanna install on my box anyway. Exeem? Chris Moneymaker's World Poker Championship? Crazy Browser? Optimal Desktop? Heck, add every piece of malware to the list and count it as an "insecure application" while you're at it.

Re:How about pointing out...

[qub333]

and more over, these were not just *nix vulnerabilities, they were *nix apps. If we included every security flaw in every program that runs on windows this year I feel that ths list might grow a bit......

--
Kevin
http://kubasik.net/blog/

Re:the thing about the list....

[beacher]

Okay I "uniqued" it by removing the (Updated)'d and it came out to 1048 - I know this isn't a good # because I didn't review if these were multiple platforms, or if they were seperate incidents within a software package...

Top 10 by bugs listed -
        * GNU GZip Directory Traversal 13
        * Multiple Vendors LibXPM Bitmap_unit Integer Overflow 13
        * Multiple Vendors Linux Kernel Multiple Vulnerabilities 13
        * GNU GZip File Permission Modification 12
        * Gzip Zgrep Arbitrary Command Execution 12
        * LBL TCPDump Remote Denials of Service 12
        * PCRE Regular Expression Heap Overflow 12
        * BZip2 File Permission Modification 10
        * GNU Xpdf Buffer Overflow in doImage() 10
        * Multiple Vendor Zlib Compression Library Decompression Remote Denial of Service 10

I was particularly surprised to see that Gentoo, RedHat and SuSE, Debian had roughly under 10 problems with their distro specific code (portage, Yast, sysreport)

It looks like there was a half assed attempt to categorize the bugs as "Multiple Vendor" and then someone gave up on it, or else someone wasn't really consistent with the counting strategy...

-B

Ignorant Users Though

[WlfRecon]

The thing is, I see most people here actually analyzing the data and seeing the flaws within it. But many many computer users will simply see the headlines and start telling everyone that there are these things called "Linux" and "Mac" that are really insecure, so everyone should use Windows.

Meaningless numbers

[laird]

These aggregate numbers are meaningless. That being said, US-CERT made pretty clear that this was simply a list of reported vulnerabilities, not any sort of analysis, so I blame the news sites with taking the meaningless numbers and trying to create a news story that will get Windows and Linux/UNIX/MacOS X fans all excited to read and post (and generate ad revenue).

Why do I say that the aggregate numbers are meaningless?
1) They count "updates" to vulnerability reports as vulnerabilities, so there are many vulnerabilities that appear to be counted 5-10 times in the "UNIX" list, and 2 times in the "Windows" list. My guess is that these "updates" are individual OS reports, meaning that a single vulnerability in a cross-platform application would be reported as 2 Windows vulnerabilities and 10 UNIX vulnerabilities. CERT should break out each OS into its own counts in order to correct for this. Eliminating duplicate reports isn't good enough, because there are many OS-specific reports, and it doesn't make much sense to count vulnerabilities specific to Solaris AND Mac OS X AND Linux AND HPUX etc., in a single number, since you run only one OS as a time. :-)
2) They count reports of multiple vulnerabilities as a single vulnerability, which means that OS's that release fewer updates, each of which patch multiple vulnerabilities (e.g. Apple, Microsoft) as having far fewer vulnerabilities than OS's that release specific patches for each vulnerability. Strangely, this punishes OS vendors that rapidly address and release patches for vulnerabilities, and reports vendors that are less responsive. CERT should count a single announcement that covers multiple vulnerabilities as if each vulnerability were reported individually.
3) They include third-party application vulnerabilities in the counts, and the number of those reports dwarfs the number of actual OS vulnerabilities (90-95% of the vulnerabilities listed aren't in the OS's). CERT should separate bugs in the OS's from optional third-party application bugs. Many of the vulnerabilities are in extremely obscure applications, and while uses of those applications might want to know about these issues, it's hardly a reflection on the OS' security if there's a 'Wojtek Kaniewski EKG Insecure Temporary File Creation & SQL Injection' in some project's "contrib" directory, which is hardly comparable to 'Sun Solaris ARP Handling Remote Denial of Service' or 'Microsoft DirectX DirectShow Arbitrary Code Execution'.
4) Their OS coverage is quite spotty. For example, if an application runs on all OS's (e.g. Mozilla, bzip) and has a vulnerability that applies to all OS's, sometimes they're reported only for Windows, sometimes only for UNIX, sometimes for both, sometimes with many repetitions and sometimes only once. While this would require CERT to do some analysis (i.e. actually read the reports), they should consistently recognize cross-OS issues and remove them from the OS-specific lists and report them in the multiple operating system list.

Since each of these issues appears to introduce error rates that are an order of magnitude larger than the useful data, there's nothing meaningful data left.

Of course, people have pointed these problems out about these CERT reports for many years. Still, since we have these same pointless discussions every year, CERT should make some basic changes to make these reports somewhat meaningful. Their previous years' list (http://www.us-cert.gov/cas/bulletins/SB2004.html) were more useful, because they at least made it clear which issues were high risk, and which application or OS each vulnerability was associated with, and they avoided the misleading totals. Let's hope that next year they at least go back to the 2004 report format, even if they don't bother to do any meaningful analysis.

Re:How about pointing out...

[david_costanzo]

and more over, these were not just *nix vulnerabilities, they were *nix apps. If we included every security flaw in every program that runs on windows this year I feel that ths list might grow a bit......

The list is supposed to include every security flaw in every program that runs on Windows. Check the Windows list; most of them are 3rd party apps and some are open source. Likewise, the UNIX/Linux list includes a lot of proprietary software. This study was examining which OS is more secure on the whole (apps and all), not if Microsoft writes more secure code than the Open Source community.

For example, take a look at Adobe's contributions to both lists.

From Windows:

• Adobe Acrobat and Reader File Discovery
• Adobe Acrobat and Reader File Discovery (Updated)
• Adobe Acrobat Reader Invalid-ID-Handle-Error Remote Code Execution (Updated)
• Adobe License Management Service Elevated Privilege Vulnerability
• Adobe SVG Viewer Lets Remote Users Determine if Files Exist

From UNIX/Linux:

• Adobe Acrobat Reader mailListIsPdf() Buffer Overflow (Updated)
• Adobe Acrobat Reader mailListIsPdf() Buffer Overflow (Updated)
• Adobe Acrobat Reader UnixAppOpenFilePerform Buffer Overflow
• Adobe Acrobat Reader UnixAppOpenFilePerform Buffer Overflow (Updated)
• Adobe Reader / Acrobat Arbitrary Code Execution & Elevated Privileges
• Adobe Reader For Unix Local File Disclosure
• Adobe Version Cue for Mac OS X Elevated Privileges
• Adobe Version Cue for Mac OS X Elevated Privileges (Updated)

Re:Suuuuure

[Bert64]

It's easy to find a crash-scenario without the sourcecode, but to actually determine if the vulnerability is exploitable or not takes a lot longer, and is much easier to find in the sourcecode.

Re:Yes, indeed.

[ajs318]

While I don't doubt that many desktop and laptop Linux / unix systems may well be running libpng, these systems most probably will be on the wrong side of a NAT box for anyone to get at them. Servers most probably won't be running X at all -- and therefore will have no need of libpng.

On a unix system, if you find something, anything, with serious enough flaws, often you can just rm it or chmod -x it until a new version is available. It'll break some things, for sure; but you have to weigh up whether the ability to display PNG images is worth more than the inability for third parties to run arbitrary code on your box {and the answer to that most probably depends on whether the system is a desktop or server}.

Anyway, the figures hardly surprise me. Everyone has access to the source code for Linux and BSD, so there are more people in a position to spot problems there {and good guys by definition outnumber bad guys}; and nobody has anything to lose from the existence of a vulnerability as long as it gets patched. But only a select few have access to the source code for Windows, and Microsoft have their own reasons for not wanting vulnerabilities to be disclosed to the public. Also, unix users seem generally to be more interested in what goes on beneath the bonnet -- and therefore more likely to apply patches in a timely fashion.

OFF TOPIC -- Good suggestion here, CowboyNeal!

[Dystopian Rebel]

I wish I could mod submissions.

Why not make this one of a subscriber's privileges?

Re:OFF TOPIC -- Good suggestion here, CowboyNeal!

[DrMorris]

What about modding the editors? I would especially like a button [decrease karma for posting a dupe... again] :-)

Re:Yes, indeed.

[The_Spud]

the exploit as I have seen it described required a deliberately malformed image as input. You would have to have a web application capable of loading arbitrary images via HTTP and doing some operation on them {perhaps overlaying a caption or copyright message, or drawing on comedy genitals}

How about a content management system that creates thumbnails or automatically resizes images, e.g. ebay image galleries or myspace ?


In which case, taking it offline for an hour or so whilst patching and recompiling whilst patching and recompiling libpng might be a small price to pay

It is a big deal to take a production server down for an hour and it could cost major money to do so.


Yes it is. There are times when access to the source code is essential. The rarity of such occasions does not diminish the usefulness of the source code if and when they arise: you have a sample size of one if the situation does arise, or nil if it doesn't, and either way that is way too few data points to be statistically significant.

This doesn't actually counter my point. You stated that there are occasions on which it is useful or even vital to be able to have the source code for software. Completely agree. This doesn't contradict the point I was trying to make that having the source available to everyone doesn't necessarily increase the amount of bugs found given the limited number of people actually have the time and expertise to look through the code.?

You seem to be forgetting that this comunity [sic] contains many people who do read source code.

Of this 'many' what proportion actually could understand something complex and specialist such as the kernel or the image processing internals of the gimp for example ?

Out of interest what software did you read the source for and have you ever actually found any flaws

Re:Yes, indeed.

[Serpent Mage]

Out of interest what software did you read the source for and have you ever actually found any flaws

Well since you are asking I found a place in the gtk (1.2) clipboard monitor code that had a potential for buffer overflow due to not using the glib wrappers for a pointer initialization.

I've also accidentally traced down a problem that I thought was in the eclipse swt 3.1.1 api down to a firefox memory overflow with closing open tabs with content in the clipboard (which was fixed up in 1.5 never checked to changelogs to see if it was retrofitted into the 1.0.x series though and don't care)

I helped out with evolution when it was still in the "how the heck do you even compile this crap" phase and found a couple of flaws as well. Of course nothing in there was really good code at the time and being that it was like 90% hacks in lots of places at that time, that may or may not count.