Working with an Online and Offline Computer when using GnuPG - Best Practice?

[Peter Lebbing]

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>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20171010/f78a04c8/attachment.sig>