Potential CVE due to malicious UUID conflict?

Potential CVE due to malicious UUID conflict?

[Timothy Pearson]

I was recently informed on #btrfs that simply attaching a device with the same UUID as an active BTRFS filesystem to a system would cause silent corruption of the active disk.

Two questions, since this seems like a fairly serious and potentially CVE-worthy bug (trivial case would seem to be a USB thumbdrive with a purposeful UUID collision used to quietly corrupt data on a system that is otherwise secured):

1.) Is this information correct?
2.) Does https://lkml.org/lkml/2019/2/10/23 offer sufficient protection against a malicious device being attached iff the malicious device is never mounted?

Thank you!

Re: Potential CVE due to malicious UUID conflict?

[Anand Jain]

On 13/11/19 9:37 AM, Timothy Pearson wrote:
> I was recently informed on #btrfs that simply attaching a device with the same UUID as an active BTRFS filesystem to a system would cause silent corruption of the active disk.
> 

> Two questions, since this seems like a fairly serious and potentially CVE-worthy bug (trivial case would seem to be a USB thumbdrive with a purposeful UUID collision used to quietly corrupt data on a system that is otherwise secured):
> 
> 1.) Is this information correct?
> 2.) Does https://lkml.org/lkml/2019/2/10/23 offer sufficient protection against a malicious device being attached iff the malicious device is never mounted?
> 
> Thank you!
> 

  Corruption of the data is not possible at all. Because when the device
  is mounted its already been excl-opened for RW and we won't
  close/replace it unless unmounted. And while the device is mounted
  if there is malicious device with the same UUID, then any scan shall
  fail with -EEXIST if the kernel has the commit as in [2] (above).

  However if the kernel does not have [2], then it will just
  appear as if the original device path has been replaced, but
  underneath the RW IOs are still going to the original device
  and not to the malicious device, so its safe.


HTH

Thanks,
Anand

Re: Potential CVE due to malicious UUID conflict?

[Timothy Pearson]

----- Original Message -----
> From: "Anand Jain" <anand.jain@oracle.com>
> To: "Timothy Pearson" <tpearson@raptorengineering.com>, "linux-btrfs" <linux-btrfs@vger.kernel.org>
> Sent: Tuesday, November 12, 2019 9:41:21 PM
> Subject: Re: Potential CVE due to malicious UUID conflict?

> On 13/11/19 9:37 AM, Timothy Pearson wrote:
>> I was recently informed on #btrfs that simply attaching a device with the same
>> UUID as an active BTRFS filesystem to a system would cause silent corruption of
>> the active disk.
>> 
> 
>> Two questions, since this seems like a fairly serious and potentially CVE-worthy
>> bug (trivial case would seem to be a USB thumbdrive with a purposeful UUID
>> collision used to quietly corrupt data on a system that is otherwise secured):
>> 
>> 1.) Is this information correct?
>> 2.) Does https://lkml.org/lkml/2019/2/10/23 offer sufficient protection against
>> a malicious device being attached iff the malicious device is never mounted?
>> 
>> Thank you!
>> 
> 
>  Corruption of the data is not possible at all. Because when the device
>  is mounted its already been excl-opened for RW and we won't
>  close/replace it unless unmounted. And while the device is mounted
>  if there is malicious device with the same UUID, then any scan shall
>  fail with -EEXIST if the kernel has the commit as in [2] (above).
> 
>  However if the kernel does not have [2], then it will just
>  appear as if the original device path has been replaced, but
>  underneath the RW IOs are still going to the original device
>  and not to the malicious device, so its safe.
> 
> 
> HTH
> 
> Thanks,
> Anand

Thank you, that helps greatly!  I was very concerned when I heard that info on IRC, and wanted to verify here.

Aside from the "interesting" corruption bug we hit on 5.3-rc3, BTRFS has been overall very stable and reliable for us.  I'm glad we don't have to worry about this type of attack (or admin oops, for that matter).

Potential CVE due to malicious UUID conflict?

[Maksim Fomin]

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, 13 November 2019 г., 4:37, Timothy Pearson <tpearson@raptorengineering.com> wrote:

> I was recently informed on #btrfs that simply attaching a device with the same UUID as an active BTRFS filesystem to a system would cause silent corruption of the active disk.

BTRFS has two UUIDs: the "UUID" and "UUID_SUB".

> Two questions, since this seems like a fairly serious and potentially CVE-worthy bug (trivial case would seem to be a USB thumbdrive with a purposeful UUID collision used to quietly corrupt data on a system that is otherwise secured):

Are you from security area? These people seem to be desperate in finding real security holes so they try to present any software error as a CVE. For example, they tried to present initrd pass through to root console [1] or systemd lauching a service with root permissions as a CVE [2]. Regarding this btrfs uuid issue - the data will be silently corrupted, but this "CVE" would require physical access to machine (like in initrd case). Besides, this issue is known for a long time. Bad news, no one will earn a CVE badge for reporting this issue. Security trolls should find hope somewhere else.

[1] https://www.cvedetails.com/cve/CVE-2016-4484/

[2] https://www.securityweek.com/linux-systemd-gives-root-privileges-invalid-usernames