On Sat, Mar 7, 2020 at 12:21 PM Grant Edwards <grant.b.edwa...@gmail.com> wrote:
>
> On 2020-03-07, Rich Freeman <ri...@gentoo.org> wrote:
>
> > In this case we're talking about a TPM where a threat model
> > is an attacker with physical access that is trying to play games with
> > the busses/etc, and as such it is important that it initialize using
> > code in ROM that is known-good.
>
> Note that the person behind the attack doesn't need physical
> access. If an attacker can shove malicious firmware into something
> like a PCI card with DMA bus-master capabilities, then on power-up
> that card can carry out the attack.  However, getting the firmware
> into the PCI card would probably require root privledges, so there
> would need to be a pre-existing privledge-elevation vulnerability.

That is a really good point.

Attackers with root access are still a concern.  You could have a zero
day in your system, then somebody breaks in, and then they install
some rootkit in your video card or something else capable of
exploiting this flaw.  They leave no other traces on your system.
Then the next day you patch your system to close the zero day, but
unknown to you there is a rootkit already installed.  Even wiping your
drives and reinstalling would not remove it in this scenario.

And the firmware updates won't cover you in this case.  Of course,
exploiting this in software probably requires other vulnerabilities in
other pieces of hardware.  Also, exactly what kind of hardware access
is required isn't disclosed anywhere I can see, so exactly what sorts
of attacks like this would/wouldn't work is hard to tell.

Of course, attacks mediated through hardware in your system like this
are a bigger issue than just this particular flaw.  Most of those can
be mitigated through IOMMU and so on, so that your graphics card can't
just go reading encryption keys out arbitrary process memory, and so
on.  However, the key here is that you install something that lurks
until reboot and then exploits the CPU to get its hooks into the
system early enough that it has control over the IOMMU and so on,
before any OS even initializes.  The security modules in the CPU are
supposed to secure the IOMMU using ROM-based code and so on before
anything important is in RAM, and while I didn't dig into the details
that sounds like where the fault lies.

-- 
Rich

Reply via email to