Richard Stiennon at ZDNet argues that Apache is inherently less vulnerable to attacks than IIS, because it makes less system calls over the course of serving an HTML page, and is therefore less vulnerable to things like buffer overflow attacks. The argument, while have some prima facie appeal, is specious. Let us examine in depth the truth about what he says:
Both images are a complete map of the system calls that occur when a web server serves up a single page of html with a single picture.
It is odd, but I cannot remember the last time a Web server was exploited on basic static HTML serving functionality. Why? Because there is nothing to attack! The serving of static HTML pages simply does not leave room for a buffer overflow, because the server is not running any arbitrary code; all it is doing is mapping the URI request to a local file, and streaming the file to the client with the appropriate HTTP headers at the top. That is it. How are you going to attack that, except for attacking the method that the server uses to process the headers, or maybe getting it to serve a file it should not?
The more system calls, the greater potential for vulnerability, the more effort needed to create secure applications.
I can agree with this. Except there is one little problem: Apache cannot be compared to IIS! Take a close look at what Apache does, out of the box: it serves static web pages. CGI is disabled by default. Even if CGI were to be enabled any vulnerabilities at that point are not in Apache, but with whatever is fulfilling the CGI request. IIS, on the other hand, has all sorts of functionality built into it, such as running ASP scripts, .Net applications, and so on and so on that Apache cannot do without the aid of third party (or non-default) extensions. What does the system call tree look like for the entire LAMP stack compared to the Windows/IIS/ASP.Net/SQL Server stack? I bet they look much more similar. Sorry pal, but you are using an apples-to-oranges comparison when comparing IISs system calls to Apaches.
Furthermore, how often does the Web server itself get attacked? Not nearly as often as the applications running on the Web server. Poor programming habits (such as not properly validating data, misuse of routines line printf() on input that was not validated, and so on and so on) are the cause of Web application vulnerabilities. There are not many Web server vulnerabilities out there now, or ever.
Poor systems administration is another source of common attacks. I dont care what OS you are running, when you have your Web server running as root or Administrator because that is easier than properly setting up permissions, you have a problem. A Perl script that is running as root outside of a chroot jail is much more of a problem that even the naughtiest ASP.Net application running on IIS as a restricted user. Period.
Ignorance and laziness are the root cause of the vast majority of security breaches, not the servers OS or application stack. PERIOD. No OS or Web server in the world will protect you if a programmer sticks the input from a Web form into the WHERE clause of a SELECT statement against a SQL injection. No amount of anti-virus or anti-whatever will help you if you have a sys admin who lets the user upload a file to an area outside the acceptable area and then execute that file while the Web server runs as root. No firewall will save you if the programmer uses a function with a known vulnerability on data that has not been scrubbed.
Those are the facts. Mr. Stiennon, I suggest that you learn the facts. You may not be a journalist and just a blogger (I am assuming by that, you mean I write subjectively, not objectively which equates to this is my opinion, not fact), but you still have a responsibility as a representative (employed or not employed) of a publication that is well regarded.
Justin James is the Lead Architect for Conigent.