2

What should be the ideal course of action for a GPU that is suspected compromised, for example by a virtual machine using passthrough?

Are there any ways to detect such an infection?

If the computer's OS is reinstalled with the GPU still connected, will it be able to attack the OS?

Is it possible to "clean" the GPU, for example reset the firmware if it is infected?

user220850
  • 101
  • 5
  • GPU are connected to system bus through PCIe Bus, has full physical memory DMA access. Anything can happen ! – Stman Jun 17 '17 at 23:06
  • @Stman Modern hardware has an IOMMU configured by the BIOS' DMAR that can mitigate evil busmastering, so DMA at least is not always a security risk. – forest Jan 02 '18 at 09:31

1 Answers1

2

It depends on how exactly it was compromised.

Unlike your PC, the GPU has no dedicated area to keep the user-uploaded information persistent between reboots (but see below). Thus any possible infection shall not survive the power off, after which your GPU is a clean slate again. It is possible, of course, that the malware on your PC will reinfect the GPU again once it is booted up, but in this case the source of compromise is your OS, and you shall focus on disinfecting your OS.

However some GPUs have firmware which is flashable by user - comparing to, for example, factory-only flashable firmware. Thus it is possible that a malicious actor would patch a firmware for your GPU, and flash it. This would require significant effort, and at this moment you should be only concerned about it if you think of a reason a three-letter agency would be after you. If you're concerned about it, you can reflash your GPU using the original firmware (although in this case your ability to obtain a copy of clean firmware would also be limited).

It is also possible that the malicious code is injected into GPU on factory, and then shipped to you. In this case you'd have no means to detect this.

Saying so, GPU attack vector has its limitations. While it can read and modify the arbitrary memory data undetected (including ignoring memory protection flags), it has no access to MMU and no way to know which physical memory regions are mapped to virtual regions. Thus making the attack happen (for example granting a certain process admin privileges) would be very difficult to perform. And the lack of internal persistent storage and other means to exfiltrate the data makes it way more difficult than traditional malware.

George Y.
  • 3,504
  • 2
  • 10
  • 15
  • I'm no hardware export, but can't option ROMs be written to on all PCI/PCIe devices since they use flash, regardless of whether or not the GPU's own personal firmware is flashable? E.g. http://resources.infosecinstitute.com/pci-expansion-rom/ – forest Jan 02 '18 at 09:29
  • Once your GPU runs an infected firmware, it can access the host memory through DMA. (In theory, it might be restricted by IOMMU, but the GPU can also attack you when you are booting, which is unlikely to be properly restricted by IOMMU…) – v6ak Feb 26 '19 at 21:51
  • @forest That is a known exploit, and is prevented by denying the guest access to PCI configuration space. – Demi Apr 15 '19 at 04:31
  • @Demi Indeed. However PCI passthrough (as mentioned by the OP) does allow guest access to PCI configuration space, at least by default (I think ACS can prevent that). – forest Apr 15 '19 at 06:11
  • @forest It doesn’t on QubesOS, at least. At least not full access. – Demi Apr 15 '19 at 11:40
  • @Demi Are you sure, even for the VMs with access to said PCI devices (e.g. NetVM's access to the NIC)? – forest Apr 16 '19 at 01:45
  • @forest I am. An exploit that allowed `sys-net` to break out to dom0 would be considered very severe, and probably fatal, by the Qubes team. – Demi Apr 16 '19 at 02:40
  • @Demi It wouldn't break out even if the PCI device were compromised due to SRTM-based measured boot. – forest Apr 16 '19 at 02:42
  • @forest QubesOS supports measured boot, but it’s optional, and its security in no way relies on it. – Demi Apr 16 '19 at 02:43
  • Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/92486/discussion-between-forest-and-demi). – forest Apr 16 '19 at 02:45