>>> ... Putting
>>> a secure application on top of an insecure O/S leaves you insecure.
>>
>>This is correct. But I think it's important to understand what "on top"
>>means. As I understand it, when Firewall-1 is installed on a Solaris
>>machine, the filtering code goes between the driver and the rest of the
>>OS. So who cares if the OS is "insecure" when the OS won't see any
>>packets it's not supposed to based on the filters that are defined.
>>In this case FW-1 is not really installed "on top" of the OS but
>>"inside" (or underneath?); a subtle but important distinction.
Firewall-1 and our product have a roughly similar architecture. You
are correct in your understanding of where the filtering code gets run.
(e.g. before the IP stack gets to mess with the bits.) The idea is to
enforce the local security policy as early as possible, rather than
waiting for the bits to climb all the way through the stack.
Sorry if that smells like a plug.
>I disagree and maintain that the O/S is still potentially vulnerable.
>One example: Suppose the FW-1 is permitted to receive e-mail from the
>Outside (Internet). What happens when a cracker sends a mail which
>exploits a sendmail bug & uses it to take control of the firewall.
If you're going to allow this kind of thing, then, potentially, any
firewall is vulnerable to the same attack. Suppose Brand-X Firewall
allows user-level applications (e.g. mail) to run on behalf of requests
from the outside. There isn't much you're going to do to stop a bug in
one of these from stomping all over your machine, if the attacker knows
how to exploit the 'bug'. Even if you're 'hardened' your OS.
>The next two questions aren't directed to you, rather they are just
>food for thought. Wasn't there (yet another) sendmail bug posted
>just a couple of months ago? How many times does sendmail have to
>be fixed before we don't have any more problems with it?
The problem is not limited to sendmail, and sendmail bugs aren't the
only well-known 'holes' in various flavors of Un*x.
Jim
Follow-Ups:
|
|
