windows vs. linux system call complexity

[quadz]

Salutations,

This has long been my intuition about windows vs. linux from a programmer's perspective... but it's amazing to see it visually!

http://www.thisisby.us/index.php/content/why_windows_is_less_secure_than_linux

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. The same page and picture. A system call is an opportunity to address memory. A hacker investigates each memory access to see if it is vulnerable to a buffer overflow attack. The developer must do QA on each of these entry points.  The more system calls, the greater potential for vulnerability, the more effort needed to create secure applications.

The first picture is of the system calls that occur on a Linux server running Apache. According to Netcraft this is pretty much the most common web server configuration on the Internet.

The second image is of a Windows Server running IIS, Microsoft's web server application.

Image: Linux / Apache System Calls Graph

Image: Windows Server / IIS System Calls Graph

[reaper]

Gotta figure the sites run in application pools and can't access memory that is used for other sites.  I believe they have their own  stack and heap.  Then the process you have execute the code of your choice has user rights restricting what it can do.  On top of that you have new features in Vista like http://en.wikipedia.org/wiki/Data_Execution_Prevention

So I'm  not sure if that benchmark you listed have any importance.  Just some thoughts.

[QwazyWabbit]

SYSTEM calls or FUNCTION calls? The images are too small to be useful.
Yep, one diagram has more lines and bubbles than the other but what are the functions in the bubbles?
What percentage of the total functions called are critical to serving the page vs. simply logging the activity?
What proportion of the total take "untrustworthy" user input?
If you can't control the input to the functions then you cannot exploit them.

Is it easier to analyze 50 functions for exploitation or 200 functions? Yes, if one assigns some "probability" to a function's exploitability then as a system 200 calls of any type can be less secure but one can also assign a zero probability to some of them (knowing they are not vulnerable) but an attacker may not be able to "know" that, he would have to spend time looking for vulnerabilities in more functions, not just randomly pick one. He has more cherries in the basket but he doesn't know which ones are sweetest until he tries them.

I also see a lot of cascade lines in the Apache diagram where there is a series of calls (10+) in a row before some terminus, would it be possible to pass arguments into the initial function in that chain such as to cause a failure in the 7th function that could allow an attacker some advantage that looking at the individual functions would not reveal?

Simply counting "calls" is not a valid metric for assessing the securability or stability of a system. It makes it hard to TEST the system but it doesn't invalidate the quality of the system if it is properly tested. If such were the case, the F-117A wouldn't fly.

[quadz]

Gotta figure the sites run in application pools and can't access memory that is used for other sites.  I believe they have their own  stack and heap.  Then the process you have execute the code of your choice has user rights restricting what it can do.

Yes, I wish they were more clear on precisely what was meant by "system calls".  Traditionally system calls implies priveleged code, on the kernel side of the fence, executing with fewer restrictions than application code.

In any case, my own interest in the graphs was somewhat less from a security standpoint, but more from a complexity standpoint -- cohesion and coupling between subsystems.

In no way would I attempt to claim the unix/linux architects got everything right.  But just the same, in my estimation, programmers who place a high value on concepts like simplicity and elegance, are likely to experience less joy working with many windows system level API's than comparable unix system level API's.

No doubt there are exceptions--John Carmack observed that Microsoft eventually evolved the Direct3D API into something laudable.

But... jesus, try writing a single threaded app on windows that deals with nonblocking file i/o, socket i/o, and events... it's gruesome.  Even a concept as simple as popen() is bizarrely complicated on windows...

As far as I can tell, windows is distinctly lacking in any guiding architectural metaphors in its core design.  What else would allow sockets to emerge as separate, unequal entities incompatible with "other" file handles.

Another example... folks have complained about select() on unix, because although it's conceptually simple, it becomes inefficient when querying large numbers of handles.  A valid criticism.  So substitute mechanisms have emerged like epoll or kqueue.  But here's the important part: changing an application from select to epoll or kqueue is easy.

On windows, even if we ignore that sockets use select while file handles use WaitForMultipleObjects... the nearest equivalent to epoll and kqueue on windows seems to be IO Completion Ports... where, as far as I can tell, you pretty much get to rewrite your application if you want to change over to IOCP.

Microsoft's own explanation...

http://msdn.microsoft.com/en-us/magazine/ms810436.aspx

Coding IOCPs can be a bit of a hassle. This is because IOCPs are somewhat counterintuitive. Let's look back at the one-thread-per-client strategy I discussed earlier. If every thread has to keep track of only one dedicated communication with a client, the control flow in the server's thread function is very straightforward: Read a client's command, execute it, and then return the value to the client. The thread function simply mirrors the control flow between the server and the client.

However, in a multithreaded scenario using IOCPs, the control flow of a thread function is less straightforward, because there is no relationship between threads and communications. In other words, a worker thread must prepare to be woken up by any I/O call from any client, decode the client from the IOCP return code, determine where in its control logic the client is (that is, what kind of input or output the client expected at that particular time), and then service the request and eventually dispatch another I/O call to return the result from servicing the request. Look at it this way: When coding dedicated threads, you can focus on the interaction between the client and the server (which is reflected in the thread function, as I mentioned before), whereas in the IOCP solution, you must focus on the worker thread, which does not reflect a client/server interaction. Later on, I will show you how you can view a client/server interaction as a automaton that can easily be implemented in a client-specific data structure.

Now that you have a shady idea of what IOCPs are, let's see how they look in practice.
...
Let's reiterate where the big problem is for the worker thread when dealing with I/O completion ports: Whenever an asynchronous I/O call has completed, it is easy for the thread to determine which client is responsible for the I/O—this can be derived from the key parameter as we discussed before—but it is not straightforward to determine which I/O the client completed.

Fun, fun.  Take something potentially simple and make it complicated.  From the "it works so it can't be wrong!" school of design.

Reminds me of quote from an MS Access tutorial manual, which was presumably stated without a shred of irony: Programmatically is a Microsoft euphemism for 'with many lines of code.'

Yes.  Yes it is.

I could go on with additional examples of needless complexity in the windows APIs, but anyway...

Basically, that spaghetti system call graph looked just like I would have expected it to look on windows.


"Any intelligent fool can make things bigger and more complex... It
takes a touch of genius - and a lot of courage to move in the opposite
direction." -- Albert Einstein


Regards,

quadz

[reaper]

I understand why people like unix like OS'es, I love them myself.  It's so easy to accomplish a lot quickly, with tools that have easy help, and tie together nicely.  Nothing is holding you back from doing this on Windows with powershell, or even the cmd shell, but a few small hurdles.  Personally I do without the small hurdles.  Like Vista got rid of telnet by default... wth is that!
Then there is no apt-get telnet.. so I really don't like it.

As far as what happens in the background when you make a web server call, I think there is some apples and oranges type comparions.  IIS is a complicated web server, but for very good reason, plus the security is there now.

[reaper]

I'm pretty sure Microsoft has quiet the talent, given all that money : ), probably much more than the open source community , imo.  But their goals reach different ends.

Microsoft does quite a lot better than open source in many respect, and vice versa.  That's the way I see it anyways.  Maybe it is easier for the people at Microsoft to work with their own software, maybe they have automated tools etc, who knows?

[reaper]

you might appreciate this quadz.

http://support.microsoft.com/kb/823764

Seems like working with sockets is a lot easier on *nix.  I just pipe output to netcat, works pretty easy..