Return to Answer

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.

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.

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.

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.

##DMA attacks

##Kernel driver exploits

##Network abuse

DMA attacks

Kernel driver exploits

Network abuse

##Kernel exploits

##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.

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

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.