Re: attacking btrfs filesystems via UUID collisions?

Am Thu, 17 Dec 2015 03:25:50 + (UTC) schrieb Duncan <1i5t5.dun...@cox.net>: > So it's definitely _not_ something that reiserfsck would do in a > "normal" fsck, only when doing "I'm desperate and don't have backups, > go to the ends of the earth if necessary to recover what you can of > my

Re: attacking btrfs filesystems via UUID collisions?

On Thu, 2015-12-17 at 03:25 +, Duncan wrote: > So it's definitely _not_ something that reiserfsck would do in a > "normal"  > fsck, only when doing "I'm desperate and don't have backups, go to > the  > ends of the earth if necessary to recover what you can of my data, > and  > yes, I

Re: attacking btrfs filesystems via UUID collisions?

Christoph Anton Mitterer posted on Wed, 16 Dec 2015 13:03:24 +0100 as excerpted: > Human readable lables are basically guaranteed to collide, Heh, not here, tho one could argue that my labels aren't "human readable", I suppose. grep LABEL= /etc/fstab | cut -f1 LABEL=bt0238gcn1+35l0

Re: attacking btrfs filesystems via UUID collisions?

Christoph Anton Mitterer posted on Wed, 16 Dec 2015 16:04:03 +0100 as excerpted: > On Wed, 2015-12-16 at 09:41 -0500, Chris Mason wrote: >> Hugo is right here.  reiserfs had tools that would scan and entire >> block device for metadata blocks and try to reconstruct the filesystem >> based on

Re: attacking btrfs filesystems via UUID collisions?

On Tue, 2015-12-15 at 08:54 -0500, Austin S. Hemmelgarn wrote: > Except for one thing:  Automobiles actually provide a measurable > significant benefit to society.  What specific benefit does embedding > the filesystem UUID in the metadata actually provide? I guess that's quite obvious. You want

Re: attacking btrfs filesystems via UUID collisions?

On Tue, 2015-12-15 at 14:18 +, Hugo Mills wrote: >    That one's easy to answer. It deals with a major issue that > reiserfs had: if you have a filesystem with another filesystem image > stored on it, reiserfsck could end up deciding that both the metadata > blocks of the main filesystem *and*

Re: attacking btrfs filesystems via UUID collisions?

On Tue, 2015-12-15 at 11:03 -0500, Austin S. Hemmelgarn wrote: > May I propose the alternative option of adding a flag to tell mount > to > _only_ use the devices specified in the options? That's one part of exactly what I propose since a few days :-P (no one seems to read my mails ;-) ) Plus

Re: attacking btrfs filesystems via UUID collisions?

On Wed, Dec 16, 2015 at 01:03:38PM +0100, Christoph Anton Mitterer wrote: > On Tue, 2015-12-15 at 14:18 +, Hugo Mills wrote: > >    That one's easy to answer. It deals with a major issue that > > reiserfs had: if you have a filesystem with another filesystem image > > stored on it, reiserfsck

Re: attacking btrfs filesystems via UUID collisions?

On Wed, 2015-12-16 at 09:41 -0500, Chris Mason wrote: > Hugo is right here.  reiserfs had tools that would scan and entire > block > device for metadata blocks and try to reconstruct the filesystem > based > on what it found. Creepy... at least when talking about a "normal" fsck... good that btrfs

Re: attacking btrfs filesystems via UUID collisions?

On Tue, 2015-12-15 at 14:42 +, Hugo Mills wrote: >    I would suggest trying to migrate to a state where detecting more > than one device with the same UUID and devid is cause to prevent the > FS from mounting, unless there's also a "mount_duplicates_yes_i_ >

Re: attacking btrfs filesystems via UUID collisions?

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

Re: attacking btrfs filesystems via UUID collisions?

On 2015-12-15 09:42, Hugo Mills wrote: On Tue, Dec 15, 2015 at 09:27:12AM -0500, Austin S. Hemmelgarn wrote: On 2015-12-15 09:18, Hugo Mills wrote: On Tue, Dec 15, 2015 at 08:54:01AM -0500, Austin S. Hemmelgarn wrote: On 2015-12-14 16:26, Chris Murphy wrote: On Mon, Dec 14, 2015 at 6:23 AM,

Re: attacking btrfs filesystems via UUID collisions?

On 2015-12-14 16:26, Chris Murphy wrote: On Mon, Dec 14, 2015 at 6:23 AM, Austin S. Hemmelgarn wrote: Agreed, if yo9u can't substantiate _why_ it's bad practice, then you aren't making a valid argument. The fact that there is software that doesn't handle it well would

Re: attacking btrfs filesystems via UUID collisions?

On Tue, Dec 15, 2015 at 08:54:01AM -0500, Austin S. Hemmelgarn wrote: > On 2015-12-14 16:26, Chris Murphy wrote: > >On Mon, Dec 14, 2015 at 6:23 AM, Austin S. Hemmelgarn > > wrote: > >> > >>Agreed, if yo9u can't substantiate _why_ it's bad practice, then you aren't > >>making

Re: attacking btrfs filesystems via UUID collisions?

On Tue, Dec 15, 2015 at 09:27:12AM -0500, Austin S. Hemmelgarn wrote: > On 2015-12-15 09:18, Hugo Mills wrote: > >On Tue, Dec 15, 2015 at 08:54:01AM -0500, Austin S. Hemmelgarn wrote: > >>On 2015-12-14 16:26, Chris Murphy wrote: > >>>On Mon, Dec 14, 2015 at 6:23 AM, Austin S. Hemmelgarn >

Re: attacking btrfs filesystems via UUID collisions?

On 2015-12-14 19:08, Christoph Anton Mitterer wrote: On Mon, 2015-12-14 at 08:23 -0500, Austin S. Hemmelgarn wrote: The reason that this isn't quite as high of a concern is because performing this attack requires either root access, or direct physical access to the hardware, and in either case,

Re: attacking btrfs filesystems via UUID collisions?

On 2015-12-15 09:18, Hugo Mills wrote: On Tue, Dec 15, 2015 at 08:54:01AM -0500, Austin S. Hemmelgarn wrote: On 2015-12-14 16:26, Chris Murphy wrote: On Mon, Dec 14, 2015 at 6:23 AM, Austin S. Hemmelgarn wrote: Agreed, if yo9u can't substantiate _why_ it's bad

Re: attacking btrfs filesystems via UUID collisions?

On Mon, 2015-12-14 at 14:26 -0700, Chris Murphy wrote: > The automobile is invented and due to the ensuing chaos, common > practice of doing whatever the F you wanted came to an end in favor > of > rules of the road and traffic lights. I'm sure some people went > ballistic, but for the most part

Re: attacking btrfs filesystems via UUID collisions?

On Mon, 2015-12-14 at 13:55 -0700, Chris Murphy wrote: > I'm aware of this proof of concept. I'd put it, and this one, in the > realm of a targeted attack, so it's not nearly as likely as other > problems needing fixing. That doesn't mean don't understand it better > so it can be fixed. It means

Re: attacking btrfs filesystems via UUID collisions?

On Mon, 2015-12-14 at 08:23 -0500, Austin S. Hemmelgarn wrote: > The reason that this isn't quite as high of a concern is because > performing this attack requires either root access, or direct > physical > access to the hardware, and in either case, your system is already > compromised. No

Re: attacking btrfs filesystems via UUID collisions?

On 2015-12-13 19:27, Christoph Anton Mitterer wrote: On Fri, 2015-12-11 at 16:06 -0700, Chris Murphy wrote: For anything but a new and empty Btrfs volume What's the influence of the fs being new/empty? this hypothetical attack would be a ton easier to do on LVM and mdadm raid because they

Re: attacking btrfs filesystems via UUID collisions?

On Mon, Dec 14, 2015 at 6:23 AM, Austin S. Hemmelgarn wrote: > > Agreed, if yo9u can't substantiate _why_ it's bad practice, then you aren't > making a valid argument. The fact that there is software that doesn't > handle it well would say to me based on established

Re: attacking btrfs filesystems via UUID collisions?

On Sun, Dec 13, 2015 at 5:27 PM, Christoph Anton Mitterer wrote: > On Fri, 2015-12-11 at 16:06 -0700, Chris Murphy wrote: >> For anything but a new and empty Btrfs volume > What's the influence of the fs being new/empty? > >> this hypothetical >> attack would be a ton

Re: attacking btrfs filesystems via UUID collisions?

On Fri, 2015-12-11 at 16:06 -0700, Chris Murphy wrote: > For anything but a new and empty Btrfs volume What's the influence of the fs being new/empty? > this hypothetical > attack would be a ton easier to do on LVM and mdadm raid because they > have a tiny amount of metadata to spoof compared to

Re: attacking btrfs filesystems via UUID collisions?

On Sat, 2015-12-12 at 02:34 +0100, S.J. wrote: > A bit more about the dd-is-bad-topic: > > IMHO it doesn't matter at all. Yes, fully agree. > a) For this specific problem here, fixing a security problem > automatically > fixes the risk of data corruption because careless cloning+mounting >

Re: attacking btrfs filesystems via UUID collisions?

Sorry, I'm just about to change my mail system, and used a bogus test From: address in the previous mail (please replace fo@fo with cales...@scientia.net). Apologies for any inconveniences and this noise here. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature

Re: attacking btrfs filesystems via UUID collisions?

On Thu, 2015-12-10 at 12:42 -0700, Chris Murphy wrote: > That isn't what I'm suggesting. In the multiple device volume case > where there are two exact (same UUID, same devid, same generation) > instances of one of the block devices, Btrfs could randomly choose > either one if it's an RO mount.

Re: attacking btrfs filesystems via UUID collisions?

On Fri, Dec 11, 2015 at 3:21 PM, Christoph Anton Mitterer wrote: > On Thu, 2015-12-10 at 12:42 -0700, Chris Murphy wrote: >> That isn't what I'm suggesting. In the multiple device volume case >> where there are two exact (same UUID, same devid, same generation) >> instances of one of the

Re: attacking btrfs filesystems via UUID collisions?

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

Re: attacking btrfs filesystems via UUID collisions?

On 12/11/15 4:21 PM, Christoph Anton Mitterer wrote: >> Note that Btrfs is >> > not unique, XFS v5 does a very similar thing with volume UUID as >> > well, >> > and resulted in this change: >> > http://oss.sgi.com/pipermail/xfs/2015-April/041267.html > Do you mean that xfs may suffer from the

Re: attacking btrfs filesystems via UUID collisions?

A bit more about the dd-is-bad-topic: IMHO it doesn't matter at all. a) For this specific problem here, fixing a security problem automatically fixes the risk of data corruption because careless cloning+mounting (without UUID adjustments) too. So, if the user likes to use dd with its

Re: attacking btrfs filesystems via UUID collisions?

On Wed, Dec 9, 2015 at 2:48 PM, S.J. wrote: >> 1. better practices, we really need to tell users, and documentation >> writers, that using dd (or variant) to copy Btrfs volumes has a >> consequence and should not be used to make copies. > > >> 2. Btrfs needs a better way to make

Re: attacking btrfs filesystems via UUID collisions?

On 2015-12-09 16:48, S.J. wrote: >> 1. better practices, we really need to tell users, and documentation >> writers, that using dd (or variant) to copy Btrfs volumes has a >> consequence and should not be used to make copies. > >> 2. Btrfs needs a better way to make a copy of a volume when there

Re: attacking btrfs filesystems via UUID collisions?

Am 10.12.2015 13:41, schrieb Hugo Mills: On Thu, Dec 10, 2015 at 07:08:51AM -0500, Austin S Hemmelgarn wrote: On 2015-12-09 16:48, S.J. wrote: 1. better practices, we really need to tell users, and documentation writers, that using dd (or variant) to copy Btrfs volumes has a consequence and

Re: attacking btrfs filesystems via UUID collisions?

On Thu, Dec 10, 2015 at 07:08:51AM -0500, Austin S Hemmelgarn wrote: > On 2015-12-09 16:48, S.J. wrote: > >> 1. better practices, we really need to tell users, and documentation > >> writers, that using dd (or variant) to copy Btrfs volumes has a > >> consequence and should not be used to make

Re: attacking btrfs filesystems via UUID collisions? (was: Subvolume UUID, data corruption?)

Christoph Anton Mitterer posted on Wed, 09 Dec 2015 06:07:38 +0100 as excerpted: > Well as I've said, getting that in via USB may be only one way. > We're already so far that GNOME automount devices when plugged... Ugh. ... And many know that's the sort of thing that made MS so much of a

Re: attacking btrfs filesystems via UUID collisions?

1. better practices, we really need to tell users, and documentation writers, that using dd (or variant) to copy Btrfs volumes has a consequence and should not be used to make copies. 2. Btrfs needs a better way to make a copy of a volume when there are snapshots (including even rw snapshots);

Re: attacking btrfs filesystems via UUID collisions?

On Sun, 2015-12-06 at 22:34 +0800, Qu Wenruo wrote: > Not sure about LVM/MD, but they should suffer the same UUID conflict > problem. Well I had that actually quite often in LVM (i.e. same UUIDs visible on the same system), basically because we made clones from one template VM image and when that

Re: attacking btrfs filesystems via UUID collisions? (was: Subvolume UUID, data corruption?)

On Sun, 2015-12-06 at 04:06 +, 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,

Re: attacking btrfs filesystems via UUID collisions?

On 12/06/2015 09:51 AM, Christoph Anton Mitterer wrote: On Sat, 2015-12-05 at 13:19 +, Duncan wrote: The problem with btrfs is that because (unlike traditional filesystems) it's multi-device, it needs some way to identify what devices belong to a particular filesystem. Sure, but that

Re: attacking btrfs filesystems via UUID collisions? (was: Subvolume UUID, data corruption?)

On Sat, 2015-12-05 at 13:19 +, Duncan wrote: > The problem with btrfs is that because (unlike traditional > filesystems) > it's multi-device, it needs some way to identify what devices belong > to a > particular filesystem. Sure, but that applies to lvm, or MD as well... and I wouldn't know

Re: attacking btrfs filesystems via UUID collisions? (was: Subvolume UUID, data corruption?)

On Sat, 2015-12-05 at 12:01 +, Hugo Mills wrote: > On Sat, Dec 05, 2015 at 04:28:24AM +0100, Christoph Anton Mitterer > wrote: > > On Fri, 2015-12-04 at 13:07 +, Hugo Mills wrote: > > > I don't think it'll cause problems. > > Is there any guaranteed behaviour when btrfs encounters two > >

Re: attacking btrfs filesystems via UUID collisions? (was: Subvolume UUID, data corruption?)

Christoph Anton Mitterer posted on Sun, 06 Dec 2015 02:51:20 +0100 as excerpted: > You have things like ATMs, which are physically usually quite well > secured, but which do have rather easily accessible maintenance ports. > All of us have seen such embedded devices rebooting themselves, where >

Re: attacking btrfs filesystems via UUID collisions? (was: Subvolume UUID, data corruption?)

Thinking a bit more I that, I came to the conclusion that it's actually security relevant that btrfs deals gracefully with filesystems having the same UUID: Getting to know someone else's filesystem's UUID may be more easily possible than one may think. It's usually not considered secret and