Why Windows is less secure than Linux

Why Windows is less secure than Linux

Summary: This post which depicts just why Windows is less secure than Linux  has been moved to here. Update: Stiennon's blog has moved to here.


This post which depicts just why Windows is less secure than Linux  has been moved to here.

Update: Stiennon's blog has moved to here.

Topics: Operating Systems, Hardware, Linux, Open Source, Security, Servers, Software, Windows

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Modular Design is Good

    Don't shoot the messenger folks!
    D T Schmitz
    • I disagree... It's not good, it's great!

      Like Mr. Stiennon said, a picture is worth a million words(I think it's <b>supposed</b> be a thousand, though). You don't even have to be a techie to appreciate the difference in the comparison. Modularity takes some effort, but it's worth it in the end. Microsoft should work on that, given the spiderweb-like interdependencies in IIS' function calls.

      BTW, it looks like jmjames is trying to shoot the messenger, but the bullets(the links) appear to be blanks. "Uhh... ya got me, ya dirty rat!" :D
      Tony Agudo
      • Links

        Blame it on ZDNet, not me. Their sucktacular software *inisists* (even with a pre tag in there!) on putting a space in the link because it is long.

        Justin James
        • Yeah, it's got some bugs to sort out!

          Quite often when I put up a link, it gets wrapped to the next line. In fact, my first post here was supposed to be in two paragraphs. I did copy and paste the whole address now, so I can see your blog post in a new tab. It was a good blog, but I'm kinda interested in the part where you said that IIS does more out of the box than Apache, that's why there's so many function calls. I agree with that, but I think IIS shouldn't have that much functionality out of the box anyhow. It should be up to the programmer what extra functionality is required for his/her needs, but the spiderweb-like picture of IIS shows that some functionality can pop up when you least expect it. As I said before, IIS definitely needs to be more modular and lean.

          PS- If you have looked at tic swayback's suggestion to the hyperlinking problem, here it is:

          Tony Agudo
    • Messenger makes crucial mistakes, but the message is still good

      Don't get me wrong; Apache is a great piece of software. But Mr. Stiennon's comparison as well as his "facts" are wildly inaccurate. If you compare what IIS is doing vs. what Apache is doing, of course their are more system calls. Apache, in a base configuration, is little more than a simple file server. You make a request, I send a file. IIS is doing a lot more. Apache when brought to the same level of functionality as IIS (add in PHP and a few other modules) probably makes just as many system calls. Furthermore, serving static HTML pages does not open you up to attacks. Server side scripting (particularly when done wrong) is the real problem. A programmer who doesn't validate data that will be used in a SQL statement will open you to SQL injection attacks, regardless of what web server, OS, or even RDBMS you are using.

      Justin James
      • Those are application layer vulns

        System calls are the attack points for buffer overflow attempts. The system calls in these diagrams have nothing to do with the extra functionality of ISS. Those functions are not called in order to display a page of text with a single image. ISS is more complex, therfore has a greater "vulnerability surface area" to use Microsoft's term.

        A succesful beffer overlow attack requires MSFT to issue a new patch, usually "critical". SQL insertion attacks come from poor coding practices, not a problem with Windows, Linux, or the web server.
        • How do you attack a static HTML request?

          And again, just how does one go about doing a buffer overflow on a static HTML request? You are simply not getting the point here. There is virtually ZERO "vulnerable surface area" on a static HTML request (which your documents are about) since the only pieces of data that come from the user are HTTP headers. Because the web server executes zero ZERO [b]ZERO[/b] processing of the output, and barely touches the input! I really don't know who taught you about these things, but they did not know what they were talking about. Now, if you said an ASP page (even one that did not actually contain any code, but just forced itself to run through the ASP ISAPI filter), I might agree with you, because then ISAPI would stick its grubby paws all over that user data. But a static HTML request just doesn't touch the input from the user except to process the HTTP headers, so a buffer overflow is next to impossible.

          And as I already stated MANY MANY MANY times, application layer vulnerabilities are the real problem, not web server vulnerabilities. And that is my point. It doesn't matter how secure the server itself is, when the truly low hanging fruit is the applications anyways, and always will be, until people stop listening to people like and and thinking, "well, it's running on LAMP, so its secure". No. That does not make it secure. Proper programming makes something secure and people like you make the problem worse, so then companies like Webroot (your former employer) can then make money cleaning it up.

          Justin James
          • Sheesh

            Is there something woderfully static about the 1,700 system calls ISS makes to deliver a single page of content? *Any* call to memory is an opportunity to inject a buffer overflow. If you are worrying about writing vs reading look at the dozens of writes IIS (or Apache) must make to log the http request.

            The discussion at hand is about the difference in complexity between Linux-Apache and IIS-Windows. Thanks for your input on application layer security. I agree.
          • ...

            there are two sides of security, one side is the
            client that requests the page and the other side
            is the insecure asp code on the server.
            I don't think that securing the client side
            requests is a serious problem nor it is
            associated with all of those 1700 system calls
            (I mean that it is just an http header that the
            server gets). but for creating html code from
            the asp code, the number of calls is a
            serious issue. I don't believe that much of the
            1700 system calls are associated for creating an
            html document from the asp page. If so, it is a
            serious problem. However, still I don't belive
            that the number of calls for
            creating the html page from asp is no more than
            what apache has, simply by looking at that
            picture. I don't believe that picture is showing
            insecurity unless one tells me that all of those
            complexity is for creating html code from asp
            code. I mean that, I need more documentation to
            believe that all of those 1700 calls are
            associated with playing user input (e.g. the asp
            code that a hacker has legally placed on a IIS
            server) I might be totally wrong but I need more
            evidence to believe that all of those 1700 calls
            are associated with playing insecure user input.
      • Contestant #2

        (Buzzer sounds: BZZZZZZZZZZZZZZZZZZZZZZZZzzzz...)
        I am sorry. That was incorrect.

        The answer is: [b][u]Modularity[/u][/b]

        But we have a parting gift for you on your way out!

        And now for a brief station break.
        D T Schmitz
        • Reading comprehension?

          Dietrich, you are usually pretty good, but I think on this thread your reading comprehension is poor. I have stated quite a number of times, both in this thread and in my blog that modularity is exactly the reason why Apache cannot be compared to IIS, and why IIS makes so many more system calls. Apache, as a modular system, is not capable with default settings of doing anything other than serve static HTML, while IIS has a lot of non-removable, non-disablable functionality already in it. I have also mentioned a number of times that Apache, once brought up to the level of functionality of IIS through standard and non-standard extensions (mod_perl, mod_rewrite, PHP, etc.) probably makes just as many system calls as IIS. To compare the two on an out-of-the-box installation for just serving static HTML just isn't possible, it's like comparing a 1987 Monte Carlo to a new Corvette. Sure, I can make a 1987 Monte Carlo handle like a BMW 3 series and run a quarter mile in 10 seconds and still have the total cost be less than a Corvette, but the Monte Carlo needs a lot of add-ons to reach that level of functionality while the Corvette comes from the dealer with that level of performance.

          Justin James
          • Oh, I See, Said the Blind Man

            Come now.

            Have you lost your good sense of humor or, perhaps, did I strike a nerve? ;)

            I had to break out the dictionary and look up "non-disablable". Couldn't find it.

            Is that anything like 'techno-babble'? ;)

            And, hey, thanks ALOT for helping me with my reading comprehension difficulties, but I don't see where car talk has any place in a ZDNet forum!!


            Is it me Folks!? ;)
            D T Schmitz
          • Weird morning...

            To be honest, my sense of humor was missing when I wrote that this morning. I know you were probably(?) kidding with the sarcasm, but I have just been very frustrated at seeing people not actually reading things before attacking them lately. Too many times lately I'm seeing stuff like:

            Person A: Why is the water wet?
            Person B: The sky is blue because of [insert long scientific explanation here]

            It's a total shell game, and that's really what I was reacting against.

            Also apologies for the language, I was not devoting 100% attention to my typing (on the phone) and I know better... like the time recently when I said something like "interpreted language run faster than compiled languages" when I know better...

            Justin James
          • No problem whatsoever

            Everything is fine in ZDNet-landia.
            Vas Schtup?
            Vee Double-U.
            Verd Up.

            Keep the TalkBacks coming!
            Thanks J.Ja :)
            D T Schmitz
      • No, the messenger is just biased

        I wouldn't bother arguing with RS on this subject. His overly simple, 'more complicated == less insecure' argument sounds nice in theory, but falls flat on it's face if you decide to actually compare the two products objectively.

        RS is a *nix evagenlist, so no amount of evidence or sound logic will sway him. For him, *nix is the answer to everything, and to suggest that *nix has security issues, or worse is rivaled by Windnows in certain areas of security is a matter of blasphemy.

        Anyone who is interested in comparing the security of IIS and Apache might want to actually start by checking out some facts. Here is a good place to start.

        [url=http://secunia.com/product/39/]Secunia Advisories on IIS5[/url]
        [url=http://secunia.com/product/1438/]Secunia Advisories on IIS6[/url]
        [url=http://secunia.com/product/73/]Secunia Advisories on Apache 2.0[/url]
        [url=http://secunia.com/product/72/]Secunia Advisories on Apache 1.3[/url]

        But of course, *nix evangelists tend to claim that discovered vulnerabilities mean nothing when confronted with the above numbers. In that case, point them to Zone-H.org and tell them to look up defacement statistics from the last five years. You'll find that the last time IIS was shown to be compromized more than Apache was around 2002. That was [b]four years ago[/b]. There are a million version of this quote, but it goes something like this: "This who live in the past have no future." Richard had already shown his inablility to let go of the past via his past articles, which all show a theme of quoting irrelevant (old) statistics or by hanging onto long obsolete factoids about products he doesn't like. In these very talkbacks he shows this by posting a link to a vulnerability in IIS from [b]2001[/b].

    Mr. Stiennon has made some crucial mistakes in his "analysis". Let's see if ZDNet's lame comments system will let me post a link to the blog I wrote in response to this article:

    <a href="http://techrepublic.com.com/5254-6257-0.html?forumID=99&threadID=184332&messageID=1995023&id=2926438">Link</a>




    <a href="http://techrepublic.com.com/5254-6257-0.html?forumID=99&threadID=184332&messageID=1995023&id=2926438">http://techrepublic.com.com/5254-6257-0.html?forumID=99&threadID=184332&messageID=1995023&id=2926438</a>

    Justin James
    • RIght right right!

      If that's the list of hoops it jumps through for the simplest of tasks then what's going to happen when things get more complicated?? Is IIS suddenly going to start using fewer system calls? I think not...
  • Broken

    An unexpected failure has occured. It has been logged and will be addressed by support.

    Your URLs are broken, are you running Windows?
    • Broken links = ZDNet.suck.suck.suck

      I appreciate that you tried to follow the links. If you look at what I wrote, there is a SEVERE malfunction with ZDNet's comment system, it refuses to put the links up properly. It puts a space in them. Let me retry, with a pre tag on them:


      Justin James
      • You gotta paste 'em together

        You need to paste the URL together, because ZDNet's commenting system sucks. That's "Powered by WordPress" for ya, can't blame that on Microsoft. :)

        Justin James