On Sunday 23 January 2005 8:42 am, Mark Williamson wrote: > > If USB peripherals could have arbitrary access to host memory by misbehaving > then this would be a serious worry, security-wise. This is not the case for > any HC I'm aware of.
That is, from the threat analysis perspective any USB stack has a few useful structural invariants. There are very few drivers that need to the hardware directly in USB, and those HC Drivers (HCDs) are a relatively small amount of code to analyse for buffer overrun style threats ... compared to, say, "every network device driver" or "every PCI driver". On the plus side, I don't think there are many such threats the three main HCDs would be vulnerable to, but it's the Way Of Such Things that I now know the code too well to perform such analysis very well. My eyes are no longer fresh. :) On the minus side, HCD code is relatively complex. That makes it harder for ANYONE to analyse. This isn't something that can change short of the USB specification itself. In 2.6 we streamlined the reqirements for HCDs substantially, compared to 2.4 or 2.2, which has good security consequences: a simpler system spec is easier to analyse for "designed-in bugs", and it's easier to analyse and test against such a spec than a complicated one. > Of course, this doesn't rule out attacks against > vulnerabilities against specific client drivers Which is FWIW where I think most of the current threats will be found, in any USB stack not just the Linux-USB one. That, and _combinations_ of bugs that add up to strange behavior that can be turned into attacks. Compare the dynamic: hundreds of USB device drivers, most of which get little use (though class drivers, like usb-storage, are safer) ... versus three main HCDs, all of which are used by EVERYONE that works with USB. > but it's not risky in the > same way as allowing users to bring along arbitrary PCI devices and plug them > in ;-) Especially when letting the users provide the firmware for those PCI devices! FWIW I happened to come across mention of something that Microsoft is talking about which would create a class of threats specifically against Longhorn-era systems. They basically plan to support special Microsoft Descriptors in USB devices -- fetch string 0xEE and if it has one, go from there. Now _descriptors_ per se aren't necessarily a problem. Except that those will evidently (specs aren't public yet) be usable for purposes like, oh, downloading the driver. That's a great attack vector!! (I heard about other, less dangerous, uses too.) And while I'm sure that some of those drivers would be digitally signed, signatures aren't directly a mechanism to ensure that the code being inserted into the most vulnerable part of your computer is actually safe to put there. (Even when the signed code loading mechanism works correctly, which isn't a given.) Remember all those folk who were able to sign buggy ActiveX code? And in some cases, malicious code; and revoking certificates didn't work very well ... Signatures don't generally mean "I'm George, and I've posted a $5million bond against this code causing any damage to YOUR interests". They usually mean little more than "my company paid the certification authority $75, and we keep the signature key in my unlocked top desk drawer" ... which is a useful perspective to keep in mind if anyone every tries to make you think signing code is by itself a security mechanism. Despite the fact that MSFT evidently has patents pending on that stuff, I'm amused to see that it's exactly like the sort of stuff that Sun was talking about a few years ago with Java. With key differences: at least with Java devices, the downloaded driver code could really be sandboxed. Which is _by definition_ impossible with drivers linked into a kernel. - Dave ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
