Let me start off by saying security is almost never absolute. I think it approaches some really basic economics: how much do you think your opponent is willing to spend to compromise your security? How much are you willing to spend to protect it?
So there is no silver bullet. It depends on your threat model. On 10/10/17 03:57, Robert J. Hansen wrote: > The point of using the > old photoreceptor was that way we were dead certain there was no > exploitable integrated circuit in the photoreceptor... I don't really see the point of purposely reducing the bitrate of a serial link. The online system on one end of the link is potentially hostile. It can still be hostile through a completely bona fide serial link. It would be indistinghuihable from a hostile integrated circuit on the online system side of the link. I don't consider it likely that the offline computer would just start interpreting stuff sent over a serial port; there would be no software running trying to make something of the data and accidentally expose an arbitrary code execution through a flaw. Instead, there would just be a data transfer utility, let's say zmodem, which would be simple enough to audit and write in an extremely defensive manner. If you need to get data out of the offline system, you still need a wire back. If not, you can cut it. If I were making custom hardware, I'd do something like this: An ARM microcontroller with USB-device port. Connected to, ah, let's say two 20 MHz SPI links. Connected to a second identical ARM microcontroller with USB-device port. It would just offer a basic USB-to-serial interface to the connected PC. But instead of an actual regular serial interface, it would transfer all data bytes over the SPI links. The firmware of the microcontroller would be so straight-forward that you can clearly see that it will never do anything other with data on the SPI bus than relay it to the USB side. Pick a high-performance microcontroller, and you could get a 40 Mbit/s serial line. If the microcontroller connected to the online system were compromised, it could still not do anything more than send plain data bytes to the other, trusted, offline side. It can't do more than a compromised online computer could already achieve. > Yep, they are. Seen them myself in the malware lab. No further comment > available, as I'm bound by NDA-of-doom. Thanks a lot for sharing what you are allowed to divulge! I really think it's great you chose to do that. Thanks. > If you think about it for a while I'm > pretty sure you'll figure out how, but I unfortunately cannot connect > the dots for you. I wrote a quick short e-mail with food for thought, there is so much detail I left out. The first thing I can think of relates directly to left out detail. If there is a bug in a filesystem driver you have enabled, it's possible that a manipulated filesystem could trigger arbitrary code execution, with kernel privileges. This would be possible with any piece of hardware that the kernel can treat as a block device, not just SD cards. So you would need to configure your system in such a way that it never *tries* to scan any new block devices you connect to the system after it has booted[1]. This is where I don't think that you can ever be sure what Windows all does when removable storage is connected. Yet with a basic Linux or BSD system, it's much better possible to locate functionality that tries to scan removable storage. So you disable all removable storage scanning and just use an incremental tar archive directly on the block device to transfer your debian-security mirror and your encrypted/signed files. Again there is an attack surface, the tar program, but it is greatly reduced. The thing with evil USB is that there are so many device drivers with so many different functions, and any one of them can become active and start communicating with your compromised USB device. With an SD card, at least you can reduce it to something like the driver for SD storage (probably a good idea to remove SDIO drivers), the block layer, the partition table parsers (don't think you'll be able to lose those), and some more stuff. Interestingly, with (U)EFI, it's also possible there is still some firmware actually active during operation. Note that it's not enough to just actually *use* a plain tar archive directly on a block device. You need to make sure that your offline system will never *try* to interpret it differently. It's not how you use it, it's how it *can* be used. I see people sometimes forgetting this important distinction. Even if /you/ don't place a plain, unencrypted filesystem on the block device, your attacker could still do that anyway. > Yep! Been done. SATA firmware has been exploited via the JTAG > interface, new firmware loaded onto it, and been used as a vector. In fact, a good friend of mine did this and did a fantastic talk about it at the OHM2013 hackers camp: <http://spritesmods.com/?art=hddhack> He went a step further than JTAG. I'm not overly worried about JTAG-based attacks, since it requires physical access to the hard disk. If your attacker has physical access to your supposedly secure equipment, you've lost in a major way. It's over. Instead, you need the in-band firmware update ability that allows you to reflash the firmware from the PC the disk is connected to, and that is precisely what he achieved. He wrote a proof-of-concept exploit. It is not clear to me whether you are saying you have seen an actual evil exploit or not when you say "been used as a vector". Because that could also refer to a proof of concept. But this proof of concept he wrote would not actually compromise the offline computer if the offline computer just used the block device as a tar archive like I proposed for the SD card scenario above. It was written for an entirely different scenario that doesn't apply in this case. What you need in this case is something that somehow uses the SATA connection to feed the system unexpected data somewhere that gets misinterpreted and leads to compromise. I haven't heard about SATA being used in this way. Note that if the system /were/ to interpret the hard disk as a filesystem, I do expect compromise is easily possible. The kernel will expect data on the hard disk to be unchanged unless it changes it itself, so there are probably time-of-check-to-time-of-use issues for instance. Well, I'm leaving it at this. Cheers, Peter. [1] Booting with the potentially compromised SD card connected would be a bad idea for sure, since you expose it to the firmware of the computer. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
