On Sun, 2015-12-06 at 04:06 +0000, Duncan wrote: > There's actually a number of USB-based hardware and software vulns > out > there, from the under $10 common-component-capacitor-based charge- > and-zap > (charges off the 5V USB line, zaps the port with several hundred > volts > reverse-polarity, if the machine survives the first pulse and > continues > supplying 5V power, repeat...), to the ones that act like USB-based > input > devices and "type" in whatever commands, to simple USB-boot to a > forensic > distro and let you inspect attached hardware (which is where the > encrypted > storage comes in, they've got everything that's not encrypted), > to the plain old fashioned boot-sector viruses that quickly jump to > everything else on the system that's not boot-sector protected and/or > secure-boot locked, to... Well this is all well known - at least to security folks ;) - but to be quite honest: Not an excuse for allowing even more attack surface, in this case via the filesystem. One will *always* find a weaker element in the security chain, and could always argue with that not to fixe one's own issues.
"Well, there's no need to fix that possible collision-data-leakage- issue in btrfs[0]! Why? Well an attacker could still simply abduct the bank manager, torture him for hours until he gives any secret with pleasure" ;-) > Which is why most people in the know say if you have unsupervised > physical > access, you effectively own the machine and everything on it, at > least > that's not encrypted. Sorry, I wouldn't say so. Ultimately you're of course right, which is why my fully-dm-crypted notebook is never left alone when it runs (cold boot or USB firmware attacks)... but in practise things are a bit different I think. Take the ATM example. Or take real world life in big computing centres. Fact is, many people have usually access, from the actual main personell, over electricians to the cleaning personnel. Whacking a device or attacking it via USB firmware tricks, is of course possible for them, but it's much more likely to be noted (making noise, taking time and so on),... so there is no need to give another attack surface by this. > If you haven't been keeping up, you really have some reading to > do. If > you're plugging in untrusted USB devices, seriously, a thumb drive > with a > few duplicated btrfs UUIDs is the least of your worries! Well as I've said, getting that in via USB may be only one way. We're already so far that GNOME&Co. automount devices when plugged... who says the the next step isn't that this happens remotely in some form, e.g. btrfs-image on dropbox, automounted by nautilus. Okay, that may be a bit constructed, but it should demonstrate that there could be plenty of ways for that to happen, which we don't even think of (and usually these are the worst in security). You said it's basically not fixable in btrfs: It's absolutely clear that I'm no btrfs expert (or even developer), but my poor man approach which I think I've written before doesn't seem so impossible, does it? 1) Don't simply "activate" btrfs devices that are found but rather: 2) Check if there are other devices of the same fs UUID + device ID, or more generally said: check if there are any collisions 3) If there are, and some of them are already active, continue to use them, don't activate the newly appeared ones 4) If there are, and none of them are already active, refuse to activate *any* of them unless the user manually instructs to do so via device= like options. > BTW, this is documented (in someone simpler "do not do XX" form) on > the > wiki, gotchas page. > > https://btrfs.wiki.kernel.org/index.php/Gotchas#Block-level_copies_of > _devices I know, but it doesn't really tell all possibly consequences, and again, it's unlikely that the end-user (even if possibly heavily affected by it) will stumble over that. Cheer, Chris. [0] Assuming there is actually one, I haven't really verified that and base it solely one what people told that basically arbitrary corruptions may happen on both devices.
smime.p7s
Description: S/MIME cryptographic signature
