Re: Reliability of RPC services

[Jesse D. McDonald]

On Wednesday 26 April 2006 19:55, Jonathan S. Shapiro wrote:
> > It's actually a fairly limited set of devices. It doesn't include, for
> > example, USB or IEEE-1394 devices (even if they happen to be accessed
> > through a PCI controller), or (probably) ATA devices (it depends on the
> > ATA protocol).
>
> Jesse:
>
> If you believe that, you need to go read the respective specifications
> more carefully. USB and IEEE-1394 *definitely* allow remote devices to
> be masters. ATA is more SCSI-like every day. I haven't checked, but I
> bet that ATA allows it too. In fact, I'm pretty sure I remember
> disconnected operations in ATA-6, which amounts to the same thing.
>
> shap

Back when I read the USB spec (USB 1.0, just for reference) there didn't 
appear to be any support for direct device-to-device transfers. All transfers 
were performed between the device and the host, and were typically initiated 
by the host as well. There were USB "master" and "slave" devices, but these 
terms refered to the USB host and USB device ports, not DMA/bus mastering, 
which is the issue with PCI devices, and the USB "master" was always the PC, 
not the removable device (except for USB hubs). In no case was the PC the 
USB "slave". Of course, they may have changed that with USB 1.1 or 2.0.

There could be an issue with ATA, which is why I said it depends on the 
specifics of the protocol. Still, ATA at least *has* a protocol, and thus 
there is no particular reason why the trusted driver couldn't specify which 
commands untrusted drivers could send. I've never read the IEEE-1394 spec, so 
I'll leave that one alone.

Regardless of all this, if (as you say) USB and ATA devices can become bus 
masters (according to the specs[1]), then no amount of software constraints 
will protect your systems from anyone with a hostile removable device. In 
such a system it would be relatively trivial to design a USB/FireWire/ATA 
device which could compromise a system without even requiring a device driver 
to be loaded. Just plug it in and your system RAM or HDD boot sector is 
instantly overwritten with malicious code through a device-initiated DMA 
transfer.

To summarize: A user-installed device capable of bus mastering is *equivalent* 
to fully-trusted user-supplied software, in that both the device and the 
trusted software are capable of gaining complete control over the system. The 
only case where it would actually matter whether the device driver was loaded 
by the user or an administrator would be where the user did not install the 
device, or where the bus protocols are secure. The former does not appear 
particularly useful; that latter is something that we may or may not have at 
present, but which we will probably have at some point in the future as 
software security improves and more people find out just how insecure the 
hardware architecture really is. Whatever system we design should be capable 
of taking advantage of those improvements in hardware security (which could, 
for the most part, be implemented without breaking existing device 
interfaces).

[1] Technically, there is no guarantee that external devices will conform to 
the specs for the bus they connect to, and thus *no* device can be assumed to 
be safe, regardless of the software in use. The only way to eliminate /that/ 
problem would be to completely eliminate physical access to the systems, 
including wrapping the system in a Faraday cage and providing isolated I/O 
and power lines. We're apparently assuming that the risk does justify that 
kind of expense in this case.

pgpxwn279dTRn.pgp
Description: PGP signature