On Tue, 2015-12-15 at 09:19 -0500, Austin S. Hemmelgarn wrote: > Um, no you don't have direct physical access to the hardware with an > ATM, at least, not unless you are going to take apart the cover and > anything else in your way (and probably set off internal alarms). Well access to the services ports (which may be USB) is typically much easier, and doesn't require to completely dismantle the steel and so... Simply because service teams also need to access these "regularly".
But even if we don't count ATMs here, use any other publicly accessible computer terminals. Library computer, the entertainment systems in airplanes, TVs in a shopping centre, etc. pp. > And > even without that, it's still possible to DoS an ATM without much > effort. Most of them have a 3.5mm headphone jack for TTS for people > with poor vision, and that's more than enough to overload at least > part > of the system with a relatively simple to put together bit of > electronics that would cost you less than 10 USD. As I've said before,.. you always find another weak link, of course,... as it was pointed out before, USB itself is quite a security problem (firmware attacks and that like). But just because there are other issues, right now, there is no justification to make btrfs "weak" as well... because this just leads to the vicious circle, that everyone has security issues, not willing to solve them, pointing to others as an excuse. > > imageine you're running a VM hosting service, where you allow users > > to > > upload images and have them deployed. > > In the cheap" case these will end up as regular files, where they > > couldn't do any harm (even if colliding UUIDs)... but even there > > one > > would have to expect, that the hypervisor admin may losetup them > > for > > whichever reason. > > But if you offer more professional services, you may give your > > clients > > e.g. direct access to some storage backend, which are then probably > > also seen on the host by its kernel. > > And here we already have the case, that a client could remotely > > trigger > > such collision. > In that particular situation, it's not relevant unless the host admin > goes to mount them. UUID collisions are only an issue if the > filesystems get mounted. Hmm from the impression I got so far, it was not only a problem when actually mounting... but even if... this doesn't change the situation. Same problem as before, the host system may have btrfs filesystems whose IDs have leaked, the attacker may upload them as VM images as described above, and even if the host's admin doesn't want to mount those, he may mount what he considers his filsystems, which however also collide. Boom. Same issues as before. Turn it as you want, resistance is futile ;-) > > Well I think it's a proper way to e.g. handle the multi-device > > case. > > You have n devices, you want to differ them,... using a pseudo- > > random > > UUID is surely better than giving them numbers. > That's debatable, the same issues are obviously present in both cases > (individual numbers can collide too). Sure, as I've said. You always must handle the case of accidentally or maliciously colliding IDs if you count on data integrity and security. But using UUIDs makes chances at least small that you run into collisions (that users must than manually resolve somehow) *even when* you just create fresh filesystem, have no attacker and no dd or that like goes in your way. > > Same for the fs UUID, e.g. when used for mounting devices whose > > paths > > aren't stable. > In the case of a sanely designed system using LVM for example, device > paths are stable. Well, but LVM itself works with UUIDs again, so you just delegate the problem. And apart from that, with btrfs, I thought, we rather want to avoid using LVM below. > > As said before, using the UUID isn't the problem - not protecting > > against collisions is. > No, the issues are: > 1. We assume that the UUID will be unique for the life of the > filesystem, which is not a safe assumption. > 2. We don't sanely handle things if it isn't unique. Well isn't that what I've said? At least it's what I've meant ;) > > Well,... I don't think that writing *into* the filesystem is > > covered by > > common practise anymore. > For end users, I agree. Part of the discussion involves attacks on > the > system, and for a attacker it's not a far stretch to write directly > to > the block device if possible (and it's even common practice for > bypassing permission checks done in the VFS layer). Well but that's something else here what I don't think we can cover. What we must assume is, that devices show up with colliding IDs, either by "accident" or means like dd... or by an attacker somehow being able to make them show up (USB, the image upload scenarios I've described before, and so on). If the attacker can however write to *arbitrary* (and not just "his") devices, bypassing checks in the VFS layer or anything else... well than game over. He wouldn't need bothering to do a probably compelx attack based on btrfs colliding UUIDs - he could simply overwrite the root filesystem and reboot with his own malicious kernel/etc. > My point is that by changing the UUID in a superblock (and properly > updating the checksum for the superblock), you can trivially break a > multi-device filesystem. And it's a whole lot easier to do that than > it > is to do the equivalent for LVM. I'm a bit unsure what you try to show: - Arbitrarily writing into a device (e.g. in the superblock) is IMHO not common practise, an not justified by common or historical use. - If one does however do it (and it doesn't matter if the admin does it or an attacker), one would of course end up in the situation, where btrfs should detect this, and refuse mounting, fsck'ing, and that like. Problem solved. Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
