My understanding is that the Librem 5 will use a USB 3 bus to communicate with the baseband. The baseband will be running a proprietary, untrusted firmware, which may have the usual cadre of remote code execution ‘flaws’ that other phones have. USB lets a physical device register an unlimited number of logical devices on the bus. What’s to stop the baseband from registering a virtual keyboard (or some other device) on the bus and using it to attack the system?
I think it would be a good idea to port https://usbguard.github.io/ to the Librem 5 anyway. It only allows unknown usb devices to be used after the user confirmed that they should be trusted. It wouldn’t only prevent malicious actions by baseband, but also those by usb keys or other usb devices with hidden “features”.
2 Likes
Neat, glad to see that the Linux kernel has had support for properly managing USB devices for a long time. That’s pretty much exactly what I was hoping someone was working on.
This hw/fw backdoor CVE exists on 99% of all desktops, which use the ASmedia USB 3x controllers as revealed by CTS for AMD Ryzen chipsets. Though has only been reported officially for the AMD Ryzen chipset, it exists on all boards using ASmedia;
https://nvd.nist.gov/vuln/detail/CVE-2018-8935
https://nvd.nist.gov/vuln/detail/CVE-2018-8934
This allows the ASmedia chip to be reflashed with malware remotely over the network.
Asmedia controllers affect millions of Intel motherboards worldwide going back six years. In the early days of USB 3.0, before Intel added its own native chipset support, Asmedia was one of the most common third-party providers. Chips like the ASM1142 are still used on Intel motherboards today. When we looked at Newegg, nearly every USB 3.0 PCI Express card we spot-checked used an Asmedia solution — typically the ASM1042 or ASM1142.
Affected: USB ASM1142, ASM1042, ASM1142, ASM1143. SATA, ASM1061 (maybe)
TPU: Does that mean that users could protect themselves against Chimera-based keyloggers by not using certain USB ports on their system?
CTS: For keyloggers that record USB traffic from within the chipset, I believe so.
TPU: Do you think users of other CPU vendors, like Intel, are affected?
CTS: Only if they have a motherboard carrying an ASMedia USB host controller. These controllers are typically found on PC motherboards made by Taiwanese manufacturers. We’ve looked into quite a few computers made by HP, Dell, Lenovo, etc. and they were not affected.
99% Motherboards using Asmedia’s ASM1142 and not Intel’s Alpine Ridge?
CTS: ASMedia USB host controller, known as ASM1142 or ASM1042, responsible for a workstation’s USB ports; (b) ASMedia SATA controller, known as
ASM1061, responsible for a workstation’s hard drive and CD-ROM connections, and © ASMedia PCI-Express bridge controller, responsible for providing additional PCI-Express ports.
The Promontory chipset is powered by an internal microcontroller that manages the chip’s various hardware peripherals. Its built-in USB controller is primarily based on ASMedia ASM1142, which in turn is based on the company’s older ASM1042.
Other chips which are used on Intel platforms are ASMedia-Chips ASM1042, ASM1042A, ASM1142 & ASM1143. Station-drivers.com from time to time release some firmware upgrades for it, but none of them fixing the DMA problem so far, the official ASMedia page shows as for now also no information regarding to this attack.
-ASMedia-USB-3.x Controller with Keylogger and Malware Risks
TPU: A huge number of Intel motherboards uses ASMedia chips, too, mostly for additional USB 3 ports. Does that mean these are affected by vulnerabilities similar to Chimera? Does it make a difference that the chips on Intel motherboards are connected via PCIe? Which chips are we talking about?
CTS: All ASMedia USB host controllers sit on the PCI-E bus. I am talking about ASM1042, ASM1142 and ASM1143. Motherboards that have these chips have the CHIMERA backdoors as well.
A great security measure would be if AMD/ASmedia released software that allows users to re-flash, preferably over all vulnerable chipsets, all at one time, to avoid one infected firmware reinfecting another via a command and control center or other local mechanisms. If this re-flashing was done once and a while, one would be confident their hardware is no longer infected. This would make subsequent re-infections a very, very difficult and nauseous task for attackers. If the process could be optionally automated on each boot, all the better.
There is a new firmware released on Nov 15, 2018 for the Asmedia ASM-1042A to ASM-1074 USB 3.x Controllers that should allow users to flash over any malware. Problem is if the malware gets in thereafter, you may have to wait for a future FM update if it masquerades itself as the current version number, hard to say. Most flashing utils and chipsets wont allow updating to the same installed firmware. In this day and age, this is bad security policy. https://www.station-drivers.com/index.php?option=com_remository&Itemid=353&func=select&id=462&lang=en
We’re well aware of problems with USB (who isn’t these days?) and the plan is to eventually make use of something like that on the Librem 5.
3 Likes