4

I'm thinking about buying a WWAN card for my laptop (like this one here), as it is more convenient to use than USB tethering. However, I'm concerned about the security risk that comes with such a card as it is connected via PCIe.

What if there is a security vulnerability on the modem firmware running on the card? What is the maximum damage an attacker could possibly do? Can the card access memory of the host system?

Edit: I'm using Linux, and the data sheet says the card will use USB 3.0 on all systems but Windows 10. However, it is still plugged in that PCIe/M.2 slot.

jnsp
  • 385
  • 1
  • 9

2 Answers2

4

Modern, complicated PCIe device run large firmware that can, and has, been found to contain vulnerabilities that allow remote exploitation. A vulnerability on the card could allow a remote attacker to gain complete arbitrary code execution on the card and modify the behavior of its firmware. So let's assume that an attacker has found a vulnerability in your WWAN card and has successfully gained code execution privileges on the card itself. What can they do with this?

DMA attacks

When a PCIe device is present, the operating system will configure it and will usually set the bus master enable bit, a feature that allows it to perform arbitrary DMA requests (reads and writes to any memory location). Operating systems do have a way to prevent this when a modern processor is used. A processor's IOMMU is capable of filtering out DMA requests to unusual locations. When an IOMMU is properly supported and enabled, the operating system kernel will set up a small quarantine area where DMA is allowed. The PCIe device and the kernel communicate by passing data in that dedicated region. If the device attempts to write anywhere else, the IOMMU will block it.

Mitigating this is rather simple, luckily. All you have to do is ensure that the IOMMU is enabled and set to enforce. This requires the BIOS contain DMAR translation tables, a component of ACPI which tells the IOMMU what memory regions will be dedicated for DMA for which devices. On some systems, especially certain laptops, the DMAR tables can be corrupt, making it impossible to enable protections. For this reason, some Linux distributions disable the IOMMU by default. You will have to enable it by setting the intel_iommu=on or amd_iommu=force boot parameters.

Kernel driver exploits

If an IOMMU is present and enabled, the device and kernel will only be able to communicate using a dedicated region of memory where DMA writes and reads are permitted. The device will pass data structures to the kernel and will then tell the kernel to process the data by issuing an interrupt or the related MSI. When this signal is raised, the kernel will call an interrupt handler to process the data at the designated DMA buffer. With this comes the risk that this processing stage itself is buggy. Code in the kernel runs at ring 0, the most privileged protection ring, so any vulnerability in its code can be disastrous. In the case where a vulnerability can be triggered by placing malicious data in the DMA buffer and raising an interrupt, then even an IOMMU will not be able to protect you.

It is more difficult to protect from bugs in kernel drivers. It would be necessary to understand the attack surface area provided by the specific WWAN driver you will be using. This requires digging through the kernel source code. In most cases, this is more trouble than it is worth. If you cannot do that, then it may be possible to use a hypervisor like Xen to virtualize the kernel driver. This is the technique used by Qubes OS, an operating system which provides heavy hypervisor-based isolation to each hardware component. When an isolation technique like that it used, a kernel driver vulnerability's impact will be limited to that of compromising the VM used for networking isolation.

Network abuse

A WWAN device is naturally going to behave as your NIC, receiving and sending packets to the network. An oft-overlooked problem with a vulnerable NIC is the fact that any attacker that has compromised it will now be in a privileged position on the network. They will be able to modify any incoming or outgoing packets at will and can perform man-in-the-middle attacks easily. A simple attack vector would be to replace a downloaded update or executable with a malicious version. Even without privileged access to memory, a compromised NIC can do a lot of damage.

Protecting against this threat requires the same threat model as protecting against any other MITM attacker on a privileged position on the network, such as a router. Authenticated end-to-end encryption with a local hardware firewall, for example, is enough to largely mitigate any damage that could be done by a compromised NIC attempting to perform a MITM attack. This would ensure that the most malicious action the NIC could take is to degrade performance or deny service.

Glorfindel
  • 2,235
  • 6
  • 18
  • 30
forest
  • 64,616
  • 20
  • 206
  • 257
3

There are almost certainly vulnerabilities in the modem firmware, because firmware is no more secure than other lightly-tested software.)

Odds are very good that the card could engage in DMA attacks if it were exploited, and the odds of a random card like this being exploited and the malware being linux-aware both seem relatively small, unless you come to the attention of nation-state sorts of attackers.

This paper says

PCI Express peripherals are able, through DMA requests, to access other peripheral memory and the main RAM, even in the kernel memory regions, without any control of the processor. This raises a major security concerns if the peripheral is controlled by an attacker. To mitigate this threat, Intel has integrated the IOMMU hardware component, to filter PCI Express messages.

and goes onto explain that there's contention over performance. It's likely that the configuration of the IOMMU is not robustly tested.

Adam Shostack
  • 2,659
  • 1
  • 10
  • 12
  • Nation-state actors are not the only adversaries that are able and willing to exploit vulnerabilities in a device's wireless card. As for the IOMMU configuration not being tested, that is true, but it is at least easy to tell if the configuration is correct (as far as I am aware, it is as simple as checking if the DMAR tables provided by the OEM BIOS are not corrupt). – forest Jul 30 '18 at 03:02
  • Sure, lots of people can create PoC, but the key question is 'what's the risk'? And there's a chain of find a vuln, write and QA exploit, deploy is against the questioner... and I said those odds are small, not non-existent – Adam Shostack Jul 30 '18 at 15:16
  • That's true! The risk is indeed low. I actually wonder if there's a way to develop such an exploit while remaining operating system-agnostic... Perhaps hooking an interrupt handler from the IDT? – forest Jul 31 '18 at 00:52