Dave Aitel
2007-02-07 00:57:07 UTC
Graphs can be quite misleading. They make people think they see
something which is blindingly obvious, but totally wrong.
http://blogs.zdnet.com/threatchaos/?p=311
(Check out the pictures.)
"""
Windows is inherently harder to secure than Linux. There I said it.
The simple truth.
Many millions of words have been written and said on this topic. I
have a couple of pictures. The basic argument goes like this. In its
long evolution, Windows has grown so complicated that it is harder to
secure. Well these images make the point very well. 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.
"""
As soon as I saw those pictures, I was like "Hey, Sana Security guys
spend hours staring at this stuff" and lo and behold, that's where
they come from. The more system calls, the harder to secure with
Sana's particular flavor of HIDS. But not "the greater potential for
vulnerability".
You don't get to see the syscall names here, but there's a few large
segments of IIS you don't get to see anywhere in Apache are as follows
(I've read the source code for both, so bear with me):
1. The metabase - essentially a registry of configuration data that
works on a per-directory or per-page basis. This is rather complex
stuff, requiring MSRPC calls and all sorts of craziness. But it
doesn't necessarily add to the insecurity of the product.
2. Threading and impersonation. My bet is that the syscall graph he
generated for Apache was in forking mode. No need to thread or handle
asynchronous operations at all. Just read(data); handle(data).
Complexity only correlates with insecurity; it doesn't let you make
order-of-magnitude judgment calls. Especially not based on graphs like
that.
For the record, or at least, as a reminder to the record, anything
based solely on system call ordering is going to have a bugger of a
time dealing with CreateThread(). On Windows you might be better off
ignoring system call ordering entirely and dealing only with system
call arguments. Having more system calls might make the entropy of the
arguments of any one system call much smaller (ioctl() has very high
argument entropy). Based on that, Windows might actually be MORE
secure, just looked at from a different angle than the call graph he
chooses to represent.
- -dave
something which is blindingly obvious, but totally wrong.
http://blogs.zdnet.com/threatchaos/?p=311
(Check out the pictures.)
"""
Windows is inherently harder to secure than Linux. There I said it.
The simple truth.
Many millions of words have been written and said on this topic. I
have a couple of pictures. The basic argument goes like this. In its
long evolution, Windows has grown so complicated that it is harder to
secure. Well these images make the point very well. 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.
"""
As soon as I saw those pictures, I was like "Hey, Sana Security guys
spend hours staring at this stuff" and lo and behold, that's where
they come from. The more system calls, the harder to secure with
Sana's particular flavor of HIDS. But not "the greater potential for
vulnerability".
You don't get to see the syscall names here, but there's a few large
segments of IIS you don't get to see anywhere in Apache are as follows
(I've read the source code for both, so bear with me):
1. The metabase - essentially a registry of configuration data that
works on a per-directory or per-page basis. This is rather complex
stuff, requiring MSRPC calls and all sorts of craziness. But it
doesn't necessarily add to the insecurity of the product.
2. Threading and impersonation. My bet is that the syscall graph he
generated for Apache was in forking mode. No need to thread or handle
asynchronous operations at all. Just read(data); handle(data).
Complexity only correlates with insecurity; it doesn't let you make
order-of-magnitude judgment calls. Especially not based on graphs like
that.
For the record, or at least, as a reminder to the record, anything
based solely on system call ordering is going to have a bugger of a
time dealing with CreateThread(). On Windows you might be better off
ignoring system call ordering entirely and dealing only with system
call arguments. Having more system calls might make the entropy of the
arguments of any one system call much smaller (ioctl() has very high
argument entropy). Based on that, Windows might actually be MORE
secure, just looked at from a different angle than the call graph he
chooses to represent.
- -dave