Windows vs. Linux Security, Once More
TAGmclaren writes "The Register is running a very interesting article about Microsoft and Linux security. From the article: 'until now there has been no systematic and detailed effort to address Microsoft's major security bullet points in report form. In a new analysis published here, however, Nicholas Petreley sets out to correct this deficit, considering the claims one at a time in detail, and providing assessments backed by hard data. Petreley concludes that Microsoft's efforts to dispel Linux "myths" are based largely on faulty reasoning and overly narrow statistical analysis.' The full report is available here in HTML form, and here in PDF. Although the article does make mention of OS X, it would have been nice if the 'other' OS had been included in the detailed analysis for comparison."
What I would like to see is some security comparison of Microsoft software and FOSS, corrected for target size.
/. can come up with a good test, and some people can carry it out?
FOSS advocates often whine about MS insecurity, whereas MS advocates often claim MS only gets more break-ins because it's used more. The MS folks are probably not right in the Apache vs IIS case, but what about other cases? Is FOSS really more secure?
Unfortunately, I cannot think of any good way to measure this. Perhaps a little brainstorm on
Please correct me if I got my facts wrong.
Windows Design
Windows has only recently evolved from a single-user design to a multi-user model
Windows is Monolithic by Design, not Modular
Windows Depends Too Heavily on the RPC model
Windows focuses on its familiar graphical desktop interface
Linux Design
Linux is based on a long history of well fleshed-out multi-user design
Linux is Modular by Design, not Monolithic
Linux is Not Constrained by an RPC Model
Linux servers are ideal for headless non-local administration
Oh yeah thats unbiased.
Two roads diverged in a wood, and I - I took the one the bus load of girls just went down.
I look forward to the Fedora SELinux project getting a good workable set of policies so that SELinux can default to being on for Fedora installs. Once that happens the "Linux is more Secure" claim will actually have some serious hard evidence behind it. SELinux and other Mandatory Access Control systems (anything hooking into the Linux Security Module in the kernel really) really are a serious step up in security, and there really is nothing comparable in the windows world.
A good way to think of MAC or SELinux is as a firewall between processes on your machine and the files and devices etc. on your machine. At the kernel level there is a set of rules, at pretty much as fine a grained level as you care to write, as to what can access what. It's well worth readign the FAQ to et a fuller idea of what we're talking about here.
Jedidiah.
Craft Beer Programming T-shirts
Ask some people that admin a mixed environment. Our Linux boxes get owned just the same as our Windows boxes do. When comparing older version of windows there is no doubt Linux owns windows but 2003 server it a pretty big improvement in security over NT 4.0 or 02. SP2 (with firewall) is also a huge improvement, just too bad it took MS this long to get it.
Saying Java is nice because it works on all OS's is like saying that anal sex is nice because it works on all genders.
Nice fuzzy logic there. How many of those 40 Microsoft vulnerabilities were related to Internet Explorer? Yes, it's Microsoft's fault for integrating it in the OS, but if you are using Server 2003 O/S to cruise the web with an admin rights role, you are the security problem, not the OS.
Why don't we look instead at security vulnerabilities in a Server OS that are relative to functions a server should be performing. How many vulnerabilities has IIS 6.0 had versus Apache in the year and a half Server 2003 has been out?
Hmmm one of those has had zero, and it sure the hell ain't Apache.
http://www.infoworld.com/articles/hn/xml/02/09/05/ 020905hnmssecure.html
OK, shocker subject line. But, in a sense, it's true!
I've read about the fact that while XP/SP2 contains numerous changes that present real improvements, it is largely a recompile of XP with a new compiler that enforces buffer size.
While that doesn't fix buffer overrun bugs, it certainly limits their potential negative security implications. When will this buffer enforcement be available for gcc!?!? I know, there are 3rd party apps, but as long as it's a 3rd party app, I won't get these benefits with a torrent-obtained Debian CD...
I would be perfectly happy to live with a few percentage points of performance hit to get this benefit!
I have no problem with your religion until you decide it's reason to deprive others of the truth.
I used to wonder at the blinders-on group think of the hidden source folks. The elaborate unreality of their arguments was a puzzle, until I figured it out. Now I understand; it's all about the dream.
While some might dismiss the article because he is a Linux advocate, that's missing the point. His piece is geared toward Linux advocacy, but avoids the usual rhetoric. I kept looking for the usual Gates bashing, but didn't find any.
What I found instead were hard facts, distilled from public data. He didn't say, "I performed some tests which prove Linux is better." He took the publicly available information, analyzed it, and reported the results.
The response by the Microsoft marketing droids and vassal fudmeisters will be instructive to anyone who really thinks about it. Don't take away their dreams of a gold mine, at least not until they've got a Ferrari just like the guy in the next cube.
sigs, as if you care.
That's sort of the point. You have to reboot a Windows server more often. If rebooting once a month or so is acceptable (see Murphy's Law for schedule), then that's fine.
If you want it to stay up, doing its job, then don't run Windows on it.
sigs, as if you care.
Basically, as bad as the CERT search system is, it's a wonder anybody can figure anything out at all about the security of computer systems. It may be better than nothing, but not by much. The security of the internet as a whole and of individual systems depends on CERT. For CERT's search to suck this badly hurts us all, so while I laud the author for mentioning it, that subject is worth of an article on its own, IMHO.
Check out my sci-fi/humor trilogy at PatriotsBooks.
Just as the authors of this report claim "it takes only a little scrutiny to debunk the myths and logical errors behind the oft-repeated axioms (that suggest Windows is more secure)" their myth busting arguments also do not stand up to scrutiny.
For one, they speak at length about the uptime of web servers. While some downtime is related to security flaws, there is not a direct corrospondance between security flaws and uptime. I find this metric completely unreliable as a method of assessing web server security.
This is essentially their only argument for the first two myths.
For the third, they mention that flaws Microsoft will NEVER fix. They don't bother to mention that these flaws only occur in older, "obsolete" operating systems. Does Red Hat issue patches for version 1.0 anymore? The rest of their argument makes much more sense, however.
(Haven't read the rest yet.. but this thus far makes me skeptical that this is an unbiased report.. )
I am the maverick of Slashdot
You are right in your assessment: the Linux kernel is monolithic and the Windows one modular, but that's totally irrelevant.
When have you seen the last vulnerability in either kernel? NTOSKRNL (or vmlinuz) isn't really the problem, it's all the crappy rest which is. Sure there have been some, but the vast majority of flaws are in various userland software. And Windows certainly is monolithic and Linux very modular, we aren't comparing kernels, but systems as a whole.
Indeed you are correct.
If he explores all forms and substances Straight homeward to their symbol-essences; He shall not die.
Not that Linux is any better. The RPC systems for Linux/UNIX are clunky afterthoughts built on top of sockets.
No matter how you cut the vulnerabilities in Win2K3 some of the vulnerabilities are definitely part of IIS 6.0. However I don't believe for a second that Microsoft is reporting all security problems, such as this problem that M$ still hasn't acknowledged.
The Apache group is much more forthcoming about security problems and I don't trust Windows as a server platform.
Now, take a recent Linux box (the distro doesn't matter) and apply all official patches and upgrades, as released by the distro and the various package maintainers.
Each machine must have directly comparable software installed. Where possible, this should actually be the same software. You don't want to have too many variables in this. You're going to have some, but by keeping things uniform, you should be able to keep things sane. The other thing is that you want SOME closed-source software on Linux and SOME open-source software on Windows.
Before we do the tests, we need some diagnostics software on the machines. Memory bounds checkers, system load monitors, host intrusion detection software, etc. This will tell us what impacts we are having, beyond simply seeing if the servers and/or OS fall over or not.
At this point, we get to the tests themselves. Throw absolutely everything you can at the computers. Use every vulnerability scanner on the planet, every worm or trojan you can locate, use stress-testers, etc. Find DoS and DDoS packages, if any have been openly released.
Now we have some actual data, based on comparable usage and comparable attacks. The data will show that the different OS' respond differently to different attacks. (Surprise there, Sherlock!) We now need to determine which of the remaining variables are important.
The remaining variables are "underlying flaws within the OS", "inherent flaws, due to errors in the design methodology itself" and "unequal reporting of equal errors".
What you want to do then is a four-way analysis of variance. The first of the three components is the different vulnerabilites found within the different applications. The second way is looking at the variation between the different vulnerabilities within the OS' themselves. The third way is the variation of bugs reported for any given application, OS or combination, vs. what actually gets reported by groups such as CERT. The fourth way would be the difference in licensing policy.
The NULL Hypothesis for the applications is that all applications will have roughly the same number of vulnerabilities, regardless of what they do, what they're written for, the philosophy of the programmer, and the company producing the software.
It's doubtful you'd find enough applications, and enough vulnerabilities in each, to split the study in sufficient ways to cover all these points. However, it should be possible to collect enough to do a statistically meaningful study on a few of them.
The problem with AOVs is that you've got to have a lot of data, and that the amount of data you need increases very rapidly. You do get plenty of idiots out there who ignore the confidence level and even the methods of the study, looking for any slight comment that proves whatever they're wanting to say. Other times, even nominally sane people will do this, because they want/need the results too fast or too cheaply to do the work properly.
Let's say, for example, that the number of vulnerabilities found within the applications, when studying the variance between them, is pretty random. There's no discernable pattern. Let's also say that there's no significant variance found between FOSS and Closed Source. Then, let's say that we're in the 1% confidence level for both of these, which means that this will likely hold true 99% of the time.
We could then conclude that Closed Source vs. Open Source is purely a matter of personal choice. The net difference simply isn't significant to warrant going for one and ignoring the other.
Continuing with this fictional scenario, let's say that Linux and Windows showes a VERY signficant level of variance. We know, at this point, that it's not the Closed vs. Open nature,
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
- So why is IE integrated into the kernel that the server is running on top of?
Internet Explorer has never been, isn't now and never will be integrated into the kernel. It does not run in kernel mode. The only thing that IE is integrated in is the shell environment and what Microsoft calls the "Windows Expierence". This integration with the 'expierence is the excuse they used to say that it had to be a part of Windows; it's a marketing reason, not a technical one.The Windows shell environment is like what KDE is on Linux, and IE is integrated into it like Konqueror is integrated into KDE. The kernel has nothing to do with it.
So windowsupdate.microsoft.com is an example of unprofessional design - update functionality doesn't require ActiveX in a webbrowser, as dozens of automatic update packages prove. I use automatic updates for many software products, and only windowsupdate.microsoft.com does 'require' ActiveX in a webbrowser.
The reason MS uses ActiveX at windowsupdate.microsoft.com is simple - you have to update Windows, and if you want to update Windows in a convenient way, then you have to use ActiveX and therefore Internet Explorer. It's just a part of the browser war, there is no technological necessity to use ActiveX for this purpose.
Looking at the list of stuff implemented, I don't really see a vast amount that's different. Both have a great deal on their wish-list, but have stuck almost exclusively to file access. Files are important, but they're not everything.
I'll be impressed by the first security system that provides at least two of the following:
I'm not completely sure the "Common Criteria" affect the higher-levels of the Orange Book. Last time I looked, I didn't see anything that matched the requirements of a B1 or A1 system, but I could just have missed that part.
Personally, I'd love it if someone could produce a patch - even if it never got certified by the NSA - that provided a complete B1 security model. I'm not sure how I'd react if Linux (or some other FOSS OS) reached the giddy heights of A1. Remember, while there are a tiny handful of companies that have released B1 or B2 certified systems, these aren't exactly buy-in-Walmarts off-the-shelf. Not many are made. Or tested. Or sold. Absolutely no commercial company, to the very best of my knowledge, produces an A1 system, except maybe as a one-off specifically to the Government.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Thank you for that post. Posts of that quality are a rarity on Slashdot...
I still have some concerns, though.
``At this point, we get to the tests themselves. Throw absolutely everything you can at the computers. Use every vulnerability scanner on the planet, every worm or trojan you can locate, use stress-testers, etc. Find DoS and DDoS packages, if any have been openly released.''
See, that, right there, leads to the problem I cannot see how to circumvent. You throw everything _you_ can find at the machines - but what if you can more easily find exploits for certain software than for others? Conversely, if you don't use available tools, but have a bunch of people try to break systems from scratch, their might be a bias in their skills that favors certain software.
``The third way is the variation of bugs reported for any given application, OS or combination, vs. what actually gets reported by groups such as CERT.''
I assume this corrects the problem mentioned above somewhat. You could try to exploit your test systems by hand, then compare your stast with CERT's, and conclude that either there is no apparent bias in either set of figures, or one of them is biased - but you wouldn't know which one. Or is there a thinko on my part?
I am an OS enthusiast, and I have a decent number of OSes here to test with. If I can really get convinced that such a test can be conducted in a meaningful way, I would like to actully do it.
Please correct me if I got my facts wrong.
OH and last time I checked, many Linux distros install a shell environment, with a web browser, on a generic server install. You can remove all traces of Konqueror, not just the lanucher but all the HTML rendering and stuff, without breaking KDE? Can you have KDE without any web browser components?You can replace the shell with an entirely different one if you want on Windows. No, it isn't as easy since MS doesn't provide an uninstaller: you have a good point. It is possible; see nLite or LitePC. If you remove all traces of IE, it will break the shell, though. And breaking the shell will break any apps that depend on the shell, just like removing KDE would break KDE apps that depend on it.
This fight is worse than the damn US Presidential Election. "My OS is better than your OS". BLAH, BLAH.
Do you know what matters? Cash, sales and total installations and lastly PERCEPTION.
The truth of the matter is that it doesn't matter which is better, it only matters which LOOKS BETTER, or is PERCEIVED AS BETTER or MORE SECURE for that matter.
Microsoft has pumped BILLIONS into making people BELEIVE that there products are the best,the most secure and the easiest to use and maintain. How much money has gone into the marketing of Linux vs. the amount that has goen into the marketing of Windows?
When was the last time you went to a "kick off" of a new version of the Linux Kernel?
Some people just never learn, you can spit the facts out until you are blue in the face, but the winner will have a bigger marketing budget!
People are warming up to Linux and are realizing the benfits of Linux, in addition, they are taking hard looks as to how secure their current OS is. It will tke time for the Linux based ditributions to take a foothold in the enterprise.
The problem is that Linux is so widely dispersed, there is no way that you can compete with the Marketing power of Microsoft.
I am pgnas and I support this message
I think it would be interesting to create a 3D plot of the threat space using the metrics from the article as axes. Comparing the shape and size might be enlightening.
PS Note I said "it would be interesting", not "I would be willing" - it would be a daunting task.
There are so many things wrong with that statement in the real world. Perhaps the most important one conceptually, and one that none of the other replies have touched on, is that you don't actually have to intentionally run IE in order for it to get invoked! I hear all the time how if people run Mozilla instead, all the worries with IE are gone, but that's not entirely true. It's a security risk just sitting on the disk, never intentionally used by anyone.
Second, as has already been mentioned, patches and updates? Sure, on a server you probably shouldn't be running a web browser, but you shouldn't have a videocard and monitor on a server either. In the windows world, however, both are required. There is no apt-get, there is no console-only mode.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
"Insightful!?" I can't believe this got modded insightful. It's the most idiotic non-response you could post in a security discussion. Not to mention the fact that it's just plain incorrect.
Most machines get compromised because of a hole in one of the applications they are running. If there's a hole in some app that a hacker finds out about and exploits before anybody is made aware of it, then it's the admin's fault? How?
First off this was not a "you should switch article".
Secondly if you read the article at all you would see that Petreley bends over backwards to state that his methodology is one way of doing things and others may be used.
Thirdly, since the point of the comparison was to determine the truth of a broad statement such as "X is more/less vulnerable than Y" it is reasonable to look at the data the way he described.
Lastly, an unstated goal of the paper was to determine if Microsoft's statements regarding Windows being more secure than Linux is true or not. In that respect it is imperative that the researcher use a broad description rather than rely on a specific application or set of circumstances.
The most important point of the article was that security can't just come down to which system has the most vulnerabilities reported but must take in to account at LEAST 3 factors, "potential damage", "technical feasibility of the attack", and the attackers ability to execute the attack(e.g. internet connection only required or local login necessary).
Microsoft never does such a good job of setting up a comparison and than actually reporting the results reasonably fairly. Certainly their current marketing drive isn't presenting the facts fairly.
Sure information wants to be free, but how much are you willing to pay for the packaging?
The author needed to provide some evidence that he/she did everything possible to make the argument for Windows to be stable and secure.
OK, I'll have to agree that there's a bias there. The language could be better, and there's a few areas that could be broadened: for one example... there are features of the Windows domain model that are neglected in this analysis... but the problem is they're not really given proper credit in pro-Windows white papers either, and the security problems of the single-sign-on environment need to be considered. From a trust point of view a group of Windows computers in a strongly configured domain can be compared to a single timeshared computer. They have the advantage of very strong hardware protection boundaries (separate machines), but a relatively weak multi-user protection model, and poor confidentiality.
Anyway, your approach (hack the crap out of both) isn't the only way to address the question. Taking the published data and re-analysing it to a common baseline, which is the approach this paper takes, is also useful. If you tone down the language you end up with a pretty honest comparison... I didn't see a lot missing from the discussion that could strengthen the security case for Windows.
Easy.
Solid Unix admins will fight tooth and nail before any application is ran as root. the only applications that should be ran as root are those that directly effect the kernel or system tools (that require it) directly. anyting else, and it's the unix admin being stupid for allowing it. If it's a business decision and the unix admin has no choice, then they need to make those people making the decision aware it's not their fault when the box is ultimatedly owned.
Otherwise, for unsafe apps, there's chroots you can use, there's ways now you can run an entire instance of linux within linux (I forget the name of this right now). So even if that instance is toasted, remove the file, copy a backup in, wash, rince, repeat. (and you can just recompile it with the fix when you find it).
You can firewall things off, at ports, users, groups, any mix you want. There's even APL's available you can use to lock down various things, or tie down resource usage per process, or anything else as well.
Basically, if a unix box gets owned, there's got to be some very serious questions on why it did.
Most likely it was something dumb like outdated software that should have been patched or upgraded long ago that was... shall we say... neglected.