A Better Air Gap

Bruce Schneier recently published ten rules for setting up an air-gapped computer; a computer that even the NSA can't hack, because it's not connected to the internet. His rules are practical and make sense, but, given the number of vulnerabilities regularly found in modern operating systems, I think that they need strengthening.

An air-gap is literally air separating a secure computer from the internet. Because this computer isn't physically (or wirelessly) connected to the internet, it's difficult to attack it without gaining physical access to it. (The attackers would have to break into your home or trick you into entering it.) In essence an air-gap is a manually operated firewall where you as its operator manually inspects all data that crosses it. An unconnected computer is not very useful, so Schneier proposes to move data to and from the air-gapped computer using CDs and USB sticks. And this is the basis of my reservation regarding his advice, for the amount of code involved in handling such media is non-trivial. The following table lists the number of code lines associated with the implementation of the FAT and ISO-9660 file systems, (those used for storing data in USB sticks and CDs) in the Linux and FreeBSD operating systems.

Given its size, the code can be vulnerable to attacks. These would involve the (internet connected) infected computer crafting the file system data structures on the written medium in a way that would trigger the vulnerability on the air-gapped computer that accessed it. The infected computer could store an attack payload (conceivably a root kit) in the medium's empty blocks.

My proposal for countering this threat is to avoid the use of storage media, and use a simpler low-level protocol to transfer data from one computer to the other. At the physical level this could be a serial RS-232 line. On the sending computer this can be set up with a USB to RS-232 cable. However, on the air-gapped computer I would implement the receiver in a different way. I would bypass the terminal line and USB drivers (again, too much vulnerable code), and would read the data using a simple program that would decode the bits arriving at a GPIO interface.

At a higher level I would allow the interface to be used for file transfer using a hand-written or heavily sanitized and scrutinized version of the YMODEM file transfer programs. These would be modified to do away with all non-essential protocol facilities, only receive and send files using the current directory, and limit the names and types of files that could be received.

Schneier wisely advises to stick to text files, arguing that Microsoft Office and PDF files can be dangerous due to the macros they may contain. Here again for these types of files I also worry about code vulnerabilities, like buffer overflows, associated with these file formats. The programs handling these files are simply too complex to be sure they are free from exploitable security flaws. For data that can't be transferred to the air-gapped computer as a plain text file, my proposal is to render it as NetPBM bitmaps, and transfer those. The NetPBM file format is simple enough to allow the careful scrutiny of the code that will handle it. At the receiving air-gapped computer these files can be transformed again into PDF or JPEG files for easier viewing.

Comments   Toot! Tweet Share