Re: attacking btrfs filesystems via UUID collisions?

[Christoph Anton Mitterer <calestyo@scientia.net>]

[-- Attachment #1: Type: text/plain, Size: 8768 bytes --]

On Wed, 2015-12-09 at 22:48 +0100, S.J. wrote:
> > 3. Some way to fail gracefully, when there's ambiguity that cannot
> > be
> > resolved. Once there are duplicate devs (dd or lvm snapshots, etc)
> > then there's simply no way to resolve the ambiguity automatically,
> > and
> > the volume should just refuse to rw mount until the user resolves
> > the
> > ambiguity. I think it's OK to fallback to ro mount (maybe) by
> > default
> > in such a case rather than totally fail to mount.
> About 3:
> RO fallback for the second device/partitions is not good.
> It won't stop confusing the two partitions, and even if both are RO,
> thinking it's ok to read and then reading the wrong data is bad.
Adding my two cents about that, just to emphasise it, even though S.J.
already covered it:

Even romounts, if anything is ambiguous, are evil:
Even if the filesystem itself wouldn't be destroyed by that, it could
mean that bogus data (or even evil data by an attacker) shows up in the
system that is then used and causes damage by being used.

In the "accidental" scenario, data from the wrong device could e.g.
contain outdated binaries, that still have security holes, or they
could contain lists of datasets to be deleted by some software, but
since being outdated or simply garbage, the wrong data could be
deleted.

In the "attacker" scenario,... well again as above, old binaries could
get used, or garbage data injected into the system (even if ro) could
make it compromised or be used for DoS.




In general, the longer I think about it, the more I come to the
conclusion that any form of auto activation (mounting, assembling,
rebuilding, etc.) is kind of dangerous... (see below)

And this applies in general, not just when using UUIDs,... but since in
btrfs UUIDs are the main criterion for selecting/auto-assembling these
devices, it's what applies for us here.

We have several stages, where wrong devices could be picked up and lead
to damage (either accidentally or as part of a tricky attack):
1) When the system boots, i.e. replacing parts of the system (e.g. 
   root fs) itself.
   There's little we can do here in general (regardless of UUID,
   labels or device=/dev/sda,/dev/sdb). If an attacker can exchange
   one of the devices, he may do evil things.
   That's bad of course, but I think "fixing" it, is beyond the scope
   of btrfs.
   - If e.g. the ATM has an unsecured BIOS/UEFI/bootloader and allows 
     the attacker easily to access these and select which device to 
     boot from,... well than I feel no sorry for the owner (their 
     fault).
   - If they configure their grub/initrd/etc. to boot LABEL/UUID... 
     well that's certainly handy, but it's also stupid if these boots 
     happen unattended, and there is an way around it (specify the 
     device paths or e.g. /dev/sda)... if the HDDs are properly
     secured by steel, and attacker cannot use the possibly more
     easily accessible USB bus.
   - Another way to partially help here is: use disk dm-crypt and 
     boot/assemble your system based on the dm-crypt devices.
     E.g. boot from the multi-device-btrfs 
     device=/dev/mapper/crypt1,/dev/mapper/crypt2 and so on.
     As long as the kernel and initrd (which does all that) are secure 
     (which is assumed here), then even when the attacker manages to 
     replace one of the devices, it wouldn't help him, as the he 
     couldn't present a device for which a dm-crypt mapping can be set 
     up (unless he has the keys, but then game's over anyway)

=> Long story short, if the system boots unattended, then people
   should not use UUID/LABEL to select the device, if they do, their 
   fault, not btrfs scope.
   If boots are attended, there's anyway not problem.
=> IHMO, this conceptually "fixes" (in the sense, that there's nothing
   to do specifically from the btrfs side) the possible problems of
   such a system being booted, with an attacker having replaced or 
   added some devices to it (especially when unattended).
   And also the situation, that such system was left back, in an
   incomplete multi-device state (i.e. left back unattended with a
   degraded RAID)


In other words, I think any problems, resulting of auto-
assembly/activation/mounting, based on UUIDs/device-scanning/etc. that
affect the valid system becoming running (i.e. booting) are beyond our
scope here.
Yes there are problems, but one can at least try to avoid them, by
using dm-crypt  or  device paths instead of LABELS/UUIDs, and properly
securing (i.e. steel and so on) the system disks, mainboard, bios, etc.


So the remaining issues are those we discussed already before:
The system runs already.
1) Further devices show up with colliding UUIDs /device IDs.
   a) Either none of them are used (mounted, fsck, etc.) already.
   b) Or     some of them are used (mounted, fsck, etc.) already.
2)
Further devices show up, that have no UUID / device ID collisions,
 
 but that may fit to an already used multi-device btrfs.
   E.g. in the
sense of: I have degraded RAID1 btrfs where my system
   runs upon. A
new device shows up that would fit to that btrfs.

(1) we already discussed:
Effects:
- it leads to data corruption
- attackers may use it to cause damage or even get out data
Possible solutions:
If such situations occur:
- In case (a) refuse to do (mount, fsck,  anything else from the btrfs
  tools) anything unless the user specified the devices to be used 
  manually (i.e. device=/dev/sda,/dev/sdb), perhaps even checking for,
  whether the given value, may be accidentally a UUID or label, e.g.
  /dev/disk/by-uuid/*
- In case (b), continue to use the already used/active/assembled 
  devices (because we must assume they actually belong together),
  refuse to do anything (including mounting, adding to a multi-device
  fs, starting rebuild, etc. pp.) with the others unless the user
  manually says so via device=foo,bar,baz

(2) is similar to (1), but I think we haven't discussed it already in depth.
The effects here are the same as above (i.e. accidental data corruption, or possible attacks), but here they would happen if btrfs would ever automatically assemble/add devices to an already active (possibly degraded) fs.
Examples:
- I have a degraded RAID6, one disk missing, the system is e.g.
  unattended and an attacker can plug in a USB stick with IDs that
  just match perfectly.
  If btrfs would then start to automatically add that newly appeared
  device to the fs, being happy about the fact that it can now start
  to rebuild, we'd have a problem.
  In that example, because the attacker may use that to get data out of
  the system.
  Take the same example without an attacker, a sysadmin may just
  accidentally plug in wrong HDD, that should actually serve as
  backup... it would start to get written at (this is why many HW RAID
  controllers have auto-activation disabled).
- One has a *non-degraded* RAID1, and an attacker manages to plug a
  device with matching IDs...
  If then btrfs would be happy about being able to enlarge the RAID to
  one more device, and automatically start to use that new device,
  perhaps even starting a balance, then same problem as above.
Possible solutions:
Long story short, never do auto-assemblies (i.e. add to an already active fs) in multi-device scenarios.
That is, don't do it per default.
I'd be fine if it was an option, e.g. a kernel parameter or whatever that enables btrfs to such auto assemblies, and if the documentation clearly explains the possible issues (especially security issues) implied by it.... but it shouln't be the default.


- IMHO, a fs should be secure by default, thus I think, adding devices to an already active fs (e.g. for rebuild), should never happen (by default) automatically.

- But perhaps it would be useful to have one additional option, which generally disables that (i.e. not just in case of already active devices).
That option would make it mandatory in *all* cases, that the user specifies device=/dev/foo,/dev/bar.
That behaviour may be preferred for some special use cases, and having a true option for it, may be better than just trying to get it by removing any udev scripts or so (which may get accidentally added back by the distro).





> PS: Kudos to C.A. Mitterer for discovering that problem
Thanks, guess I have a hand for thinking about such "higher-level"
attacks,... unfortunately in most cases the people aren't that open
about it as here :-/


Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5313 bytes --]