From nobody Wed Apr 02 14:24:41 2025 X-Original-To: bugs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZSRvs1Zlnz5sML0 for ; Wed, 02 Apr 2025 14:24:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZSRvs12Vrz3XQ0 for ; Wed, 02 Apr 2025 14:24:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1743603881; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=DjQvNuYRBu4bVSg5C3PqDGH+Y7r9ZmKu5GI1PdDDHDA=; b=KSXVmjcS6BrSa5conJnOoQZ4KthMDB8749DZG6smOSdT7HWnkMXPumlp1Xfx/yJnuq/ZaW iMIZ5EzBs0ujyixxFvCsejy6xus5QQ8qltnuSn+nSRVdat8aYAMagcUkfq8kpA1JRKhqyM ftLiazP4RPzHWmzw5BzOWbUBIY2Whhhapti815dm6QUgksP/mlnBpEBE9N51Xf6tT6DeN7 tLWt8URowCvaowF5unoBTxrr0/EGfX5xgZaOCLpny7F6ns9mhLNpP/oy7EvRWFgt3UkNV3 ktmW8oXB7Ea/DHiF6d3S//ZpqZzM67YWhzMBdXcyLeqP59xUy/nUeKiblCDosQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1743603881; a=rsa-sha256; cv=none; b=g7MvHoZ1yCcNOrpv8sE0mYSM7nPLPJGW5fhIsKt6QhCQh1Kmq2EHd0ER4OdpXHc3kOQc4v orBf1ibvBG6NqAF4HIxv8qXZ4c0792vQiVW61thjUIMSXxmyYv8LeVMaxPu8mW5gccwSKt eWC9OOgRAMdZri+qDQXbaqQEfrOudLc0CTf0k8QbWke9jGwgf9tFq1uR8BD0iS/J+RHYeT +WQch4fVLYlaZg56kvc7jd0+ixctswUHr7N7+3JOElWNpl1suDZBbVbJrZu63pkUfOw7sZ infbIZS4jNL8cc/IHPBgoWWGJaf4ZhP4esV5v9WTWsZXhVXSMQa6oTOcZNiWVg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1743603881; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=DjQvNuYRBu4bVSg5C3PqDGH+Y7r9ZmKu5GI1PdDDHDA=; b=DEs+HrYH0u3wiGEkvDERQDF0PQnFXuiLm+q2QmX85C1mPUXGnJa58P/4KHuB1F2avLsjLP HcfES2rJanfjZewRHTi6E3hzKP6x+rPDvftgktvtjSWczWl3CykIt2wY86ahyoWr8DzwiH yTx8Ck+ZwmC6j5jg7dFwguzE8tVrN9Xtj8Sl/10h7oCuU16KoUO7ij2k30DJZgVGyndO1S rTjcnsMn7lT5gA7xOzMUVkUYwsMYC3cz6G6Qr+vYJhiEAD/3bUjdmZgUskRSyBKIs/4FDC mOHgeOQ/oxQmD5CwYHHu6kpZfHMMe8zXlchQNqvH+fuuMgYQcCx+NK5HAeS2lQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4ZSRvs0DHdz4Kp for ; Wed, 02 Apr 2025 14:24:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 532EOejw051900 for ; Wed, 2 Apr 2025 14:24:40 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 532EOeb2051899 for bugs@FreeBSD.org; Wed, 2 Apr 2025 14:24:40 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 285849] [geli] [request] authenticated metadata block Date: Wed, 02 Apr 2025 14:24:41 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: no.spam.c@mail.ru X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-bugs@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D285849 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 =3D G_ELI_VERSION_07) isn't authenticated, its MD5 hash (md= _hash) doesn't protect against malicious modifications (it can be simply recalcula= ted 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 authenticatio= n 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 encry= pted data that mimics (when decrypted) a GEOM metadata block (like a mirror or stripe) in the last sector of the resized partition, causing unwanted effec= ts on the next attach. But, obviously, attackers need to plant that piece of d= ata 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. --=20 You are receiving this mail because: You are the assignee for the bug.=