On Fri, Jan 28, 2011 at 12:25:29PM -0600, Marsh Ray wrote: > Well, I was thinking about what the min-privilege such a device > would need. Even though most folks will probably just end up running > this code as root, in theory the driver needs to be able to only do > a few things: > * talk to the USB device, preferably in an exclusive sort of way
That's difficult without writing a kernel driver which is then even more privileged. > Thus, IF the driver/daemon for this device were compromised, we > could expect that the attacker would gain (as a minimum) local > privileges which enable him to 'lie' to the kernel about the amount > of entropy its pool contains. Aah I understand now. > Why bother with all the negotiating of authentication keys if we are > expected to trust the integrity of the USB devices? The point is that we're not trying to trust in the integrity of the USB devices; rather we're trying to authenticate them continually. Your USB device might be hundreds of miles away in a data centre and you want to be able to be sure that if its attacked, you'll know about it. > Are you sure a local-USB attacker would need to know a secret key? > It looked to me like the pem.c code ran before packet authentication > (e.g., it was used to un-PEM the MAC itself). Yes, the PEM code would be run before any authentication however no data would ever be written out dependent on this data; either to log files or to the USB device. > >If you have found a way to leak key material (or even a serious attack vector > >which could cause crashing via bad PEM input data) then I'd love to see it. > > If the key material happened to land in the right 128 bytes of RAM, > I think there's a good chance that some variant on the padding > timing or POET attack could obtain it quickly. Interestingly, I think the reverse PEM dictionary could do with being const, so that it gets put into ROMEM and thus less likely to be near dangerous data. So all in all a couple of potential fixes in that code. > If nothing else, you could obtain the memory addresses of load > modules, if defeating ASLR/PaX is a useful step in further > exploitation. Providing you can find a useful way to get that data back out of the function. Given that whatever three bytes you manage to point at will then be mangled by the PEM decode, it's not a 100% lossless acquisition of data. Still it could be a leak if you can control where that data goes usefully. All in all, the issues with pem.c don't look (to me) as though they are an easily exploited attack vector at this time so while I shall ensure the issues are corrected before the next release, I don't feel that a 'security' release is warranted. (Unless I'm totally missing your point in which case please tell me :-) > >We're always grateful to receive patches (or just directed ideas for > >improving > >the codebase). I have put "harden pem.c" on my TODO list. > > You could securely overwrite dynamic memory before free()ing it. I > didn't see that happening. Most of the memory during runtime is not static, or pertains purely to the control interface and thus we consider it to be less sensitive. However I've added a "Poisoning free block" note to the TODO. Patches gratefully received if you have time before we do. Regards, Daniel. -- Daniel Silverstone http://www.digital-scurf.org/ PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69 _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
