Re: attacking btrfs filesystems via UUID collisions?

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

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
>> have a tiny amount of metadata to spoof compared to a Btrfs volume
>> with even a little bit of data on it.
> Uhm I haven't said that other systems properly handle this kind of
> attack. ;-)
> Guess that would need to be evaluated...
>
>
>>   I think this concern is overblown.
> I don't think so. Let me give you an example: There is an attack[0]
> against crypto, where the attacker listens via a smartphone's
> microphone, and based on the acoustics of a computer where gnupg runs.
> This is surely not an attack many people would have considered even
> remotely possible, but in fact it works, at least under lab conditions.
>
> I guess the same applies for possible attack vectors like this here.
> The stronger actual crypto and the strong software gets in terms of
> classical security holes (buffer overruns and so), the more attackers
> will try to go alternative ways.
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.

I still think that that isn't a sufficient excuse for not fixing the 
issue, as there are a number of non-security related issues that can 
result from this (there are some things that are common practice with 
LVM or mdraid that can't be done with BTRFS because of this).
>
>> I'm suggesting bitwise identical copies being created is not what is
>> wanted most of the time, except in edge cases.
> mhh,.. well there's the VM case, e.g. duplicating a template VM,
> booting it deploying software. Guess that's already common enough.
> There are people who want to use btrfs on top of LVM and using the
> snapshot functionality of that... another use case.
> Some people may want to use it on top of MD (for whatever reason)... at
> least in the mirroring RAID case, the kernel would see the same btrfs
> twice.
Also, using flat DM-RAID (and yes, people do use DM-RAID without LVM), 
using the DM-cache target, some multi-path setups, some shared storage 
setups, a couple of other DM targets, and probably a number of other 
things I haven't thought of yet.
>
> Apart from that, btrfs should be a general purpose fs, and not just a
> desktop or server fs.
> So edge cases like forensics (where it's common that you create bitwise
> identical images) shouln't be forgotten either.
While I would normally agree, there are ways to work around this in the 
forensics case that don't work for any other case (namely, if BTRFS is 
built as a module, you can unmount everything, unload the module, reload 
it, and only scan the devices you want).
>
>
>>>> If your workflow requires making an exact copy (for the shelf or
>>>> for
>>>> an emergency) then dd might be OK. But most often it's used
>>>> because
>>>> it's been easy, not because it's a good practice.
>>> Ufff.. I wouldn't got that far to call something here bad or good
>>> practice.
>>
>> It's not just bad practice, it's sufficiently sloppy that it's very
>> nearly user sabotage. That this is due to innocent ignorance, and a
>> long standing practice that's bad advice being handed down from
>> previous generations doesn't absolve the practice and mean we should
>> invent esoteric work arounds for what is not a good practice. We have
>> all sorts of exhibits why it's not a good idea.
> Well if you don't give any real arguments or technical reasons (apart
> from "working around software that doesn't handle this well") I
> consider this just repetition of the baseless claim that long standing
> practise would be bad.
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 practice 
that that software is what's broken, not common practice.

The assumption that a UUID is actually unique is an inherently flawed 
one, because it depends both on the method of generation guaranteeing 
it's unique (and none of the defined methods guarantee that), and a 
distinct absence of malicious intent.
>
>> I disagree. It was due to the rudimentary nature of earlier
>> filesystems' metadata paradigm that it worked. That's no longer the
>> case.
> Well in the end it's of course up to the developers to decide whether
> this is acceptable or not, but being on the admin/end-user side, I can
> at least say that not everyone on there would accept "this is no longer
> the case" as valid explanation when their fs was corrupted or attacked.
On that note, why exactly is it better to make the filesystem UUID such 
an integral part of the filesystem?  The other thing I'm reading out of 
this all, is that by writing a total of 64 bytes to a specific location 
in a single disk in a multi-device BTRFS filesystem, you can make the 
whole filesystem fall apart, which is absolutely absurd.
>
>> Sure, the kernel code should get smarter about refusing to mount in
>> ambiguous cases, so that a file system isn't nerfed. That shouldn't
>> happen. But we also need to get away from this idea that dd is
>> actually an appropriate tool for making a file system copy.
> Uhm... your view is a bit narrow-sighted... again take the forensics
> example.
And some recovery situations (think along the lines of no recovery disk, 
and you only have busybox or something similar to work with).
>
> But apart from that,... I never said that dd should be the regular tool
> for people to copy a btrfs image. Typically it would be simply slower
> than other means.
>
> But for some solutions, it may still be the better choice, or at least
> the only choice implemented right now (e.g. I wouldn't now of a
> hypervisor system, that looks at an existing disk image, finds any
> btrfs in that (possibly "hidden" below further block layers), and
> cleanly copies the data into freshly created btrfs image, with the same
> structure.
> AFAIK, there's not even a solution right now, that copies a complete
> btrfs, with snapshots, etc. preserving all ref-links. At least nothing
> official that works in one command.
Send-receive kind of works for that, but requires down time because the 
subvolumes all have to be read-only.  In theory, it's possible, but it 
would take a lot of work, and a lot of special case handling to 
implement properly.
>
> Long story, short, I think we can agree, that - dd or not - corruptions
> or attack vectors shouldn't be possible.
> And be it just, to protect against the btrfs on hardware RAID1 case,
> which is accidentally switched to JBOD mode...