Gentoo Archives: gentoo-user

From: Rich Freeman <rich0@g.o>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Re: New Intel vulnerability?
Date: Sat, 07 Mar 2020 17:32:57
Message-Id: CAGfcS_mu=9JYcHTxTnbc=_8Y-wqybYjvBQ6VjN4ogyjc-hGuHA@mail.gmail.com
In Reply to: [gentoo-user] Re: New Intel vulnerability? by Grant Edwards
1 On Sat, Mar 7, 2020 at 12:21 PM Grant Edwards <grant.b.edwards@×××××.com> wrote:
2 >
3 > On 2020-03-07, Rich Freeman <rich0@g.o> wrote:
4 >
5 > > In this case we're talking about a TPM where a threat model
6 > > is an attacker with physical access that is trying to play games with
7 > > the busses/etc, and as such it is important that it initialize using
8 > > code in ROM that is known-good.
9 >
10 > Note that the person behind the attack doesn't need physical
11 > access. If an attacker can shove malicious firmware into something
12 > like a PCI card with DMA bus-master capabilities, then on power-up
13 > that card can carry out the attack. However, getting the firmware
14 > into the PCI card would probably require root privledges, so there
15 > would need to be a pre-existing privledge-elevation vulnerability.
16
17 That is a really good point.
18
19 Attackers with root access are still a concern. You could have a zero
20 day in your system, then somebody breaks in, and then they install
21 some rootkit in your video card or something else capable of
22 exploiting this flaw. They leave no other traces on your system.
23 Then the next day you patch your system to close the zero day, but
24 unknown to you there is a rootkit already installed. Even wiping your
25 drives and reinstalling would not remove it in this scenario.
26
27 And the firmware updates won't cover you in this case. Of course,
28 exploiting this in software probably requires other vulnerabilities in
29 other pieces of hardware. Also, exactly what kind of hardware access
30 is required isn't disclosed anywhere I can see, so exactly what sorts
31 of attacks like this would/wouldn't work is hard to tell.
32
33 Of course, attacks mediated through hardware in your system like this
34 are a bigger issue than just this particular flaw. Most of those can
35 be mitigated through IOMMU and so on, so that your graphics card can't
36 just go reading encryption keys out arbitrary process memory, and so
37 on. However, the key here is that you install something that lurks
38 until reboot and then exploits the CPU to get its hooks into the
39 system early enough that it has control over the IOMMU and so on,
40 before any OS even initializes. The security modules in the CPU are
41 supposed to secure the IOMMU using ROM-based code and so on before
42 anything important is in RAM, and while I didn't dig into the details
43 that sounds like where the fault lies.
44
45 --
46 Rich