Re: Air gap technologies

[Aleph One <aleph1 () underground org>]

So much for not posting again.

On Thu, Jan 25, 2001 at 02:21:17PM -0500, Elad Baron wrote:
> I urge you to read my complete answer from several months ago 
> (http://www.whalecommunications.com/fr_06000119.htm), where I go 
> thorough the entire security design consideration of the e-Gap, including
> answering your specific question. I know it is not a short response, but if 
> the people on this group ("intelligent consumers") *really* want to
> understand 
> what we implemented and why is it different, they should at least spend the 
> time reading it before concluding that we're peddling "gimmicks".

I did read the whole thread from back then, including your response.
I am still not convinced you've gained anything.

> "...Last, is the issue of the physical disconnect. Now that I have gone over
> the reasons why we need to separate the TCP/IP front end from the security
> policy enforcement, I can explain why we needed a physical disconnect. We
> need some kind of a gap to implement the above separation and we need a safe
> transport to shuttle data over that gap. For the transport mechanism, the
> idea is to use an existing protocol for its communication properties (i.e.
> bandwidth, industry support, wide choices of server compatibility, etc.) but
> of course, not to use a protocol that is traditionally used for networking
> (after all, we wouldn't want "smart" operating systems to bind it
> automatically to their TCP/IP stack by any chance). Sounds pretty easy -
> just pick a point to point protocol, such as RS232, SCSI, firewire, etc,
> right? Wrong! The more throughput and communication features you want, the
> more complex that P2P protocol is. And again, none of these protocols were
> designed with security in mind (for example, SCSI protocol relies on the
> "honesty" of the bus members when doing its negotiation - the lower SCSI ID
> member should stop using the bus after it loses to a higher number). By
> using such a protocol you would theoretically (and practically?) be
> vulnerable to a staged attack that exploits vulnerability in the P2P
> protocol itself. 
>
> Of course we could have created a new P2P protocol, but who would assure you
> that there are no vulnerabilities in this new protocol? 
>
> **The solution - use a standard protocol, but break it in the middle!** We
> use SCSI protocol, but this protocol is between the external e-Gap server
> and a "dumb" device (the e-Gap appliance). When this conversation is over,
> the dumb device is disconnected from the outside and physically connected to
> the internal e-Gap server (using analog switches on the SCSI wires). Then, a
> new SCSI conversation takes place between the dumb device and the internal
> server, transferring the raw data. Even if a hacker tries to exploit a
> weakness in the SCSI protocol, those attempts will not reach the inside. The
> dumb device is hard coded to "speak native and honest SCSI," and cannot be
> re-programmed or bypassed. It does not have a TCP/IP address, does not have
> an operating system, and is not programmable. Just memory banks with a SCSI
> interface, all solid state. So the only thing such a low level attack could
> achieve is a manipulation of content data, and that is being handled in the
> internal e-Gap server as explained in the previous section. 

And here is were you are wrong. The whole idea of the E-Gap and similar
products is to protect an internal server or network against attacks
at the TCP/IP layers and application layer. The reasoning behind this is 
that TCP/IP and the application protocols are complex and they are likely
to result in security vulnerabilities. Your aim is to insulate the
internal host against this vulnerabilities by replacing the TCP/IP
and application layer connectivity between the external network and
the internal host with a simpler transport and application protocols.
The assumption being that simpler transport and application protocols
are less likely to have implementation errors that may result in
security vulnerabilities.

I would consider using SCSI as your transport protocol your first error. 
I can't fathom how can you claim that RS232 is a more complex protocol then
SCSI. It seems evident that you are likely to find more implementation errors
in an implementation of SCSI than RS232.

You attempt to mitigate your selection of a complex transport protocol
by using a non-programmable non-general-purpose device that shuffles data 
between two SCSI buses by physically disconnecting from each. With this
measure you hope that an attacker that compromises the external host can't
perform attacks at the SCSI layer against the internal host. 

Of curse the shuffling device itself may be vulnerable to attacks at the
SCSI layer. The fact that its an embedded non-general-purpose device makes 
attacking it more difficult but not impossible. Attacks such a buffer
overflows are possible against the device if its SCSI protocol decoder has 
flaws.

It strikes me as interesting that the SCSI device is nothing more
than a proxy itself. In a product that is supposed to mitigate the
dangers of complex protocols you need a proxy to mitigate the dangers
of the transport protocol you have selected. 

Having such proxy is not a bad idea as it represents a defense in depth 
strategy, if it weren't for the fact that here the proxy is not a bonus
but a requirement to secure an otherwise complex protocol.

It appears to me that you could replace the SCSI device and two SCSI buses
with a normal computer with two network interfaces and a TCP or UDP
level circuit level proxy and you would have a system with the same 
security characteristics - with the exception that you got a 
programmable general purpose system as the proxy. It can be argued
whether TCP/IP or SCSI is the more complex protocol.

But what I see at the real error in your analysis is that you concentrate
on the transport layer - SCSI switch and how it protects the internal host 
against SCSI level attacks - and completely gloss over the application
level protocol your proxy software on each host are using to communicate
with each other. It's here were any vulnerabilities are likely to be 
exploited. The SCSI switch does nothing to protect the internal server 
against attacks at this layer. After all the switch is simply copying the 
data from one to the other without analyzing it.

So the real security of the product does not lie on the SCSI switch
but on the simplicity of the protocol spoken between the external and
internal proxy software and its correct implementation. 

I can't see how can you claim that the safer transport is SCSI with
a SCSI proxy and not straight RS232.

> Elad Baron
> http://www.whalecommunications.com

-- 
Aleph One / aleph1 () underground org
http://underground.org/
KeyID 1024/948FD6B5 
Fingerprint EE C9 E8 AA CB AF 09 61  8C 39 EA 47 A8 6A B8 01 
_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://www.nfr.com/mailman/listinfo/firewall-wizards