[Bug 285849] [geli] [request] authenticated metadata block

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285849

            Bug ID: 285849
           Summary: [geli] [request] authenticated metadata block
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: no.spam.c@mail.ru

# Problem

The current metadata block (in sys/geom/eli/g_eli.h: struct g_eli_metadata,
with md_version = G_ELI_VERSION_07) isn't authenticated, its MD5 hash (md_hash)
doesn't protect against malicious modifications (it can be simply recalculated
over altered metadata).

When the data authentication is enabled, this allows attackers to:

1. reduce the size of the underlying device without causing authentication
errors (i.e., by reducing the partition size, moving the metadata footer to the
"new" last sector of the partition, adjusting the md_provsize and md_hash
metadata fields), or

2. force GELI to return "authenticated garbage" for all encrypted sectors
(e.g., by changing the md_ealgo field from CRYPTO_AES_XTS to CRYPTO_AES_CBC,
this would yield incorrect decryption results, which are treated as
authenticated, because of the "encrypt-then-MAC" scheme, as the ciphertext
remains intact).

# Implications

I don't think that this is exploitable in cases when the data authentication is
enabled to protect against malicious modifications to encrypted sectors: e.g.,
through physical access, execution capabilities on the underlying storage
device, or access to a disk image being used over a network.

There could be some less-than-realistic scenarios where some piece of encrypted
data that mimics (when decrypted) a GEOM metadata block (like a mirror or
stripe) in the last sector of the resized partition, causing unwanted effects
on the next attach. But, obviously, attackers need to plant that piece of data
into the encrypted file system and know its exact on-disk location, which is
unrealistic.

So, I report this as a "defense-in-depth" feature request.

# Solution

It would be nice to have some important metadata fields HMAC-protected.

-- 
You are receiving this mail because:
You are the assignee for the bug.