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 |