Slashdot Mirror
Study Finds Windows More Secure Than Linux
cfelde writes "A Windows Web server is more secure than a similarly set-up Linux server, according to a study presented yesterday by two Florida researchers." In addition to the Seattle Times article, there is also coverage on VNUnet. From the article: "The researchers, appearing at the RSA Conference of computer-security professionals, discussed the findings in an event, 'Security Showdown: Windows vs. Linux.' One of them, a Linux fan, runs an open-source server at home; the other is a Microsoft enthusiast. They wanted to cut through the near-religious arguments about which system is better from a security standpoint."
Well, apparently this is the second time Microsoft has come out on top of a research project by Mr. Richard Ford.
http://www.virusbtn.com/magazine/articles/letters/ 2004/01_01.xml
Apparently there was some question to the validity of an earlier project because it was sponsored by Microsoft.
However, I would like to note that both researchers seem very well educated, especially in computer security. And, additionally, they both note that a lot more could be done to lock down the Linux server.
Security Innovation is a certified Microsoft partner for security services. We have both the Microsoft SWI and ACE certifications as an authorized professional services provider for Microsoft technologies.
I'll allow you to jump to your own conclusions.
And how many people run Win2003 server at home? People should understand that the plural of anecdote is not data.
If you are going to make a comment about the validity of the data, at least RTFA you ignorant clod.
"They compared Windows Server 2003 and Red Hat Enterprise Server 3 running databases, scripting engines and Web servers (Microsoft's on one, the open source Apache on the other). "
How many people run RH Enterprise Server at home?
Um, no. Your average system administrator earns about $62k has at least 2 years experience, and generally a bachelors degree in a related field. At least according to most industry figures.
The job title also entails tweaking system configurations for security, evaluating patches, etc. etc.
"Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming
They need to explain exactly what they did to come to this determination. As I read it, they compared default setups... which avoids the "security is a process, not a product" debate.
However, it sounds like they compared the number of reported vulnerabilities as if they were apples and apples--which is a big error. Open Source should yield discovery of more vulnerabilities--the more, the better it's working.
On the other hand, if critical vulnerabilities are not being patched as quickly as for Windows then that would be a problem. What are the statistics on that?
Matthew
Heroin at least has a high, MS gives your company the addiction/lockin without the fuzzy feelings.
You can be allowed to look at Microsoft's source. Governments can do this and some other people too. If you apply at the below URL you might just be that someone :)
/ li censing/getsource.mspx
http://www.microsoft.com/resources/sharedsource
Joke aside, it is possible. But you must have a good reason I guess. And "I want to see if IE can be removed from the kernel" probably isn't one of them.
My guess is that someone else in the program has Microsoft funding for his project, but you could be right. In any case, the OP's assertion is incorrect.
What I'm listening to now on Pandora...
The article compares the window of times of vulnerability between reports of security flaws and available fixes to them. Based on that, Linux should come out WAAY ahead, and yet it didn't... And then I noticed the one importat detail - they were comparing Redhat to Windows, and thus the window of vulnerabilty counts from when the vulnerability is reported to when REDHAT gets the fix packaged up and pushed out through *their* channels, which is signifigantly after the fix is available if you didn't go through redhat to get it.
So, the research is very true - a straight redhat install with no outside packages does have longer windows of vulnerability than a straight Windows install with no outside packages. But the person writing the article told a MAJOR LIE when summarizing it for the article, by attributing the long windows of time to linux in general, when really it's a problem with just redhat.
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
No offense. But it sounds like people are searching for things to dismiss this study. Um, yes, a Linux guy changed his mind after seeing the conclusions of the study. That means it's not a valid study?
Exactly. Regardless of the validity of the study the Linux community should be taking this the same way they've taken other comparisons in the past: as a spur to make the changes and improvements necessary to make Linux simply that much better than the opposition.
Right now that means, if you're a developer, you ought to be spending a little time learning about SELinux and how it works. SELinux provides a framework for security, but it is only as secure as the applications running in that framework. If the applications respect and take advantage of it, it is a huge gain, if they don't then it provides little real improvement.
One of the big security claims for Linux over Windows is user accounts. The fact is that both Windows and Linux have differing user accounts with differing permissions. On Windows, however, there are many applications that don't care about user accounts - they expect Administrator level access. On Linux non root accounts are fundamental and almost all the (user) applications understand that they can't expect to be root. That means that on Windows the user accounts and permissions, despite being implemented and available, don't provide too as much security as they do on Linux.
Right now SELinux is the same way - there's a new security framework (roles, mandatory access controls), but the applications ignore it: they fail to respect the new boundaries, or they fail to take advantage of the compartmentalization of lowest privilege systems that SELinux allows. The community needs to take the step toward embracing this new, better, security framework.
Claims like this study should be the spur to get the community to do that! Help spread awareness of the task...
Jedidiah.
Craft Beer Programming T-shirts
TFA mentions that this is a default implementation of both, unhardened. To that I would reply, "Well, DUH!!!" If your administrator doesn't know enough to grab one of the multitude of Apache hardening checklists off the web http://www.google.com/search?hl=en&lr=&q=apache+ha rdening+script then they shouldn't be allowed within 100 meters of your datacenter. Period.
Why would it take a patch to make a server run in a chroot jail? This can be done with any program. It requires no cooperation from the program itself.
Of course, running anything chrooted usually requires making a list of subprocesses that the program calls, and linking them into the program's directory tree. You'd want to do this in this case, because web servers typically do invoke some subprocesses. Not always, of course; some web sites are completely static. In any case, this doesn't require any sort of patch; just a list of what files are needed in the chroot area.
So what's in the OpenBSD chroot patch? What sort of vulnerability existed without it?
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
What on earth are you talking about? Are you trying to imply that sql injection is a windows only problem? And about 'winsock' crashing... do you know of a vulnerability we don't? Or are you harking back to windows 95 vulnerabilities? The fact is, the parent post is the one that is Insightful. Both Linux and Windows servers can be secured very easily. The XP desktop might still have issues, but Win2k3 server is solid and secure.
Sure most people will have 1 server handling all tasks running somewhere outside their reach but there are ways around having every damn service in the world open to the entire world.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
I did some work at a local University a while back. The faculty I worked in used HP-UX for their core services, Linux on the desktop, a couple of Solaris labs and 1 small (less than a dozen) windows lab. The other faculties used Windows almost exclusively.
/my2cents
The faculty that ran the *nix based services had almost no complaints of intrusion or other security problems from the "global" IS department of the university, while some of the windows using faculties were being threatened with losing their internet access because of too many security breaches.
No, this isn't a study. But it's evidence of how it works in the real world.
The reason I think *nix is more secure is because of how configurable it is. You can configure almost anything. Hell, you could write your own TCP drivers if you felt like it (not that I've ever known anyone to do that). On Windows you're limited to the security options given to you from the vendor. Or you have to pay a 3rd party for their innovation... With *nix the power is in your hands.
'Out of the box' software/systems are usually never ready for production environments right? But sufficiently tweaked most systems can be reasonably secure and centrally manageable. I just think that level of tweakability is higher with *nix.
Bruce Schneier
Posted on January 06, 2005 at 01:45 PM
------------
Different methodology, different results. My money's on Schneier.
"There are already a million monkeys on a million typewriters, and Usenet is NOTHING like Shakespeare." - Blair Houghton
Here is another related report in which Windows is compared with Linux in terms of security. Interesting read.
[alk]
Having read TFA, the "study" consisted of counting security flaws for RH and Windows, and comparing how long it took to issue patches -- from the date of the vulnerability being announced. This is really shallow; we've seen lots of such studies and laughed at them. I note the spin put on this is "One of them, a Linux fan, runs an open-source server at home..." which makes it look like a Linux zealot has been hacked in his own home, while the happy Windows guy is unscathed. In fact, it was all hypothetical, there were no trials of real servers (none mentioned anyway), just "potential" vulnerabilities in default setups.
The same cannot be said about MS IIS. Worse, the odds are very good that many the IIS exploits were in the wild prior to when they were first publicly reported, while most of the Apache exploits were, in all likelihood, patched prior to the first exploit.
Did you read the article? The server tested is Windows 2003. The web server is IIS 6.0. These "many exploits" that you refer to, which ones are they? Last time I checked there were no reported remote exploits for IIS 6.0. There ARE exploits for 2003 as a platform, but not for 6.0 as a product.
I don't believe that touchez means 'touch it', that would be touchez-la. (Or touchez-le, if one prefers to touch masculine things) By itself, touchez is the second person, plural form of toucher, or 'to touch' in English. I was correctly caught mistaking whose for who's. This was mildly embarassing, so I was joking about being stung by the comment. A judge in fencing would anounce touche, but an oponent that was struck might say 'touchez' or even 'touchez-moi' to the oponent that landed a blow.
Think global, act loco
Actually, the word is touché meaning 'touched'. The fencer would announce touché meaning 'I've been touched.' (French je suis (j'ai été) touché.) It's the gerund of the verb toucher meaning 'to touch.' touchez, apart from being the second person plural of that verb, if used alone in a sentence like that, would be considered the imperative voice. The English translation of the sentence Touchez. would be 'Touch.' I can imagine a dark corner -- oops, never mind!
Ehh no. If you want to bind to low network points, you can do that as root and then setuid(3) to another low-privilege user, or by getting a file-descriptor from another (more privileged) process, or you could get that capability granted to you by a startup-script, or another process. For web-servers, almost everybody would use the simplest solution: setuid(3).
Since the Windows security model is completely different (ie: it's more complicated than unix's "if UID != 0 then apply_security()"), the concept of chroot doesn't really need to exist.
No. The problem you mentioned isn't why chroot is useful. chroot isn't needed on unix either (in theory). Since most web-servers on unix runs as some non-privileged user anyway (as opposed to IIS which has system privileges), you are extremely way off the target.
chroot is there simply because all software has bugs. Even if there is a critical security hole in e.g. the operating system, that results in a remote vulnerability, and someone takes advantage of this, they still can't escape from the chroot'ed environment. Unless there are holes in the chroot functionality too (which could be true).
Good security practice is to do a total overkill, i.e you build your security in layers. You have one (or more) firewall(s), preferably both at the packet filtering level and the application level. You run every service with as few privileges as possible. You put them in a chrooted environment. You lock down everything you don't need. You run it on a dedicated machine (and/or use something like UML). And then you can start worrying about keeping up-to-date on patches.
By the way, the unix security model you described might have been correct in the 70's. It isn't anymore. Different unixes might do different things, but most certainly everyone will at least have various ways of escaping the need to be root to do useful stuff, e.g. capabilities, passing of file-descriptors, etc...
chroot doesn't affect a processes namespace, it just affects path name resolution so one can easily escape the chroot with "/..".
This can only work if you are root user in a chroot environment -- what any sane secure design avoids or limits to a small, secure part of code. And no one places setuid binaries into chroot environment, so privileges elevation can be only a result of a kernel bug -- what is not unheard of (recently patched in Linux), but is a very uncommon compared to other vulnerabilities.
Contrary to the popular belief, there indeed is no God.
Don't give Microsoft too much credit. Here.It's actually a really good track record, but not flawless.
regards,
Steve