lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20220812055437.GA10952@srcf.ucam.org>
Date:   Fri, 12 Aug 2022 06:54:37 +0100
From:   Matthew Garrett <mjg59@...f.ucam.org>
To:     Brendan Trotter <btrotter@...il.com>
Cc:     The development of GNU GRUB <grub-devel@....org>,
        Ard Biesheuvel <ardb@...nel.org>,
        Daniel Kiper <daniel.kiper@...cle.com>,
        Alec Brown <alec.r.brown@...cle.com>,
        Kanth Ghatraju <kanth.ghatraju@...cle.com>,
        Ross Philipson <ross.philipson@...cle.com>,
        "piotr.krol@...eb.com" <piotr.krol@...eb.com>,
        "krystian.hebel@...eb.com" <krystian.hebel@...eb.com>,
        "persaur@...il.com" <persaur@...il.com>,
        "Yoder, Stuart" <stuart.yoder@....com>,
        Andrew Cooper <andrew.cooper3@...rix.com>,
        "michal.zygowski@...eb.com" <michal.zygowski@...eb.com>,
        James Bottomley <James.Bottomley@...senpartnership.com>,
        "lukasz@...rylko.pl" <lukasz@...rylko.pl>,
        linux-efi@...r.kernel.org, linux-kernel@...r.kernel.org,
        James Morris <jmorris@...ei.org>
Subject: Re: Linux DRTM on UEFI platforms

On Fri, Aug 12, 2022 at 12:52:58PM +0930, Brendan Trotter wrote:
> Hi,
> 
> On Fri, Aug 12, 2022 at 3:55 AM Matthew Garrett <mjg59@...f.ucam.org> wrote:
> > On Thu, Aug 11, 2022 at 07:25:58PM +0930, Brendan Trotter wrote:
> > > On Thu, Aug 11, 2022 at 3:16 AM Matthew Garrett <mjg59@...f.ucam.org> wrote:
> > > > The kernel has no way to know this - *any* code you've run before
> > > > performing a measurement could tamper with the kernel such that it
> > > > believes it's fine. This is just as true in DRTM as it is in SRTM. But
> > > > you know what the expected measurements should be, so you're able to
> > > > either seal secrets to those PCR values or rely on remote attestation.
> > >
> > > In this scenario the kernel has no idea what the measurement should
> > > be, it only knows the measurement that a potentially malicious boot
> > > loader felt like giving the kernel previously (e.g. when the kernel
> > > was installed).
> >
> > Even if the kernel has an idea of what the measurement should be, it has
> > no way to verify that what it believes to be true is true - any
> > malicious code could simply have modified the kernel to believe that
> > anything it asks the TPM returns the "correct" answer.
> 
> Right. To achieve the best possible security; you'd need Secure Boot
> to ensure that the kernel itself wasn't modified, and then the kernel
> establishes a dynamic root of trust itself.

You can't rely on Secure Boot because compromised firmware might fail to 
implement it, so you're back to relying on dynamic trust.

> Anything involving a boot loader (e.g. Secure Boot ensure's boot
> loader wasn't modified, then boot loader ensure's kernel wasn't
> modified, then ....) increases the attack surface for no benefit.

I honestly feel like we're talking about different things. Can you 
describe the attack vector you're concerned about here?

> I'm not convinced an external agent can detect "bad/forged
> measurement" either. E.g. if a MiTM boot loader always provided a
> bad/forged measurement the external agent won't detect it (as the
> measurement always matches the expected measurement), and then if the
> MiTM boot loader is replaced by a good/honest boot loader the external
> agent will decide that the good/honest boot loader is malicious
> because its measurement doesn't match the expected bad/forged
> measurement.

The point of DRTM is that the platform (in the form of an authenticated 
code module running on the CPU, outside of the control of the OS) 
performs a measreument of a specific point in time. The policy it's 
provided with allows an external agent to identify which component of 
the runtime system is being measured. If an external malicious agent has 
been executed then the measurement will be different as a result.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ