Firewall Wizards mailing list archives
RE: Air gap technologies
From: Elad Baron <elad () whale-com com>
Date: Thu, 25 Jan 2001 16:51:37 -0500
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 totally missed my point. I did not say RS232 is more complex than SCSI. The opposite is true. However, if your e-Business requires bandwidth over 115.2Kbs, you must go for faster protocols, which are more complex (SCSI being an example). As you go to more complex protocols (and you went way ahead by suggesting TCP for that!) you need a method to block the vulnerabilities of this transport mechanism. This is what we achieved with the device and the disconnection. And the device itself CAN NOT be used for attacking the chosen protocol, since it is being reset before each communication session with the internal server (and the "legitimate language" of the chosen protocol is hard coded in its ROM). Of course you could build your own transport protocol from scratch and convince the world in general (and the FW-WIZ list specifically) that this protocol and its implementation are AIR tight... You are totally right that application level security is very important, but only after you secured the infrastructure it rides on. We do lots of things at the application level (e.g. URL analysis, SSL decryption/encryption, authorization, authentication); all benefit from the fact they are implemented on the trusted side of the Air Gap. Up to now, this group has chosen to focus mainly on the physical disconnection aspect of the technology, and this is why, in my opinion, missed the big picture. I can only repeat what I said in my original response: "***The secure transport mechanism we have is a means to achieve our goal; it is not the goal!***". Elad Baron http://www.whalecommunications.com -----Original Message----- From: Aleph One [mailto:aleph1 () underground org] Sent: Thursday, January 25, 2001 4:04 PM To: Elad Baron Cc: 'Avi Rubin'; firewall-wizards () nfr com; Frederick M Avolio; Crispin Cowan; Stiennon,Richard Subject: Re: [fw-wiz] Air gap technologies 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
Current thread:
- RE: Air gap technologies, (continued)
- RE: Air gap technologies Bill Stout (Jan 25)
- RE: Air gap technologies Elad Baron (Jan 25)
- Re: Air gap technologies Avi Rubin (Jan 25)
- RE: Air gap technologies Frank Knobbe (Jan 25)
- RE: Air gap technologies daN. (Jan 25)
- RE: Air gap technologies Elad Baron (Jan 25)
- Re: Air gap technologies David Wagner (Jan 25)
- Re: Air gap technologies Adam Shostack (Jan 26)
- Re: Air gap technologies Aleph One (Jan 25)
- Re: Air gap technologies David Wagner (Jan 25)
- RE: Air gap technologies Bill_Royds (Jan 25)
- RE: Air gap technologies Elad Baron (Jan 25)
- Re: Air gap technologies Aleph One (Jan 25)
- Re: Air gap technologies Aleph One (Jan 25)
- Re: Air gap technologies Aleph One (Jan 25)