Librem 5 affected by Chimera? (HW/FW backdoor in ASmedia USB 3.X host controllers)


#1

Is libram 5 using Intel based USB host controllers or ASmedia? “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.”

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, (2018) 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. It can take months and even years for new FW to come out. Most flashing utils and chipsets wont allow re-flashing 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

On top of that, a hardware switch to disable flashing of devices would be a win-win-win.


#2

Other posts covering this topic: Librem 5: Securing usb bus?
Is asmedia silicon in Purism Laptops a security risk?


#3

I don’t believe there are any publicly known backdoors in Intel based USB 3.x controller chipsets.


#4

The Librem 5 will be using a USB controller built into the I.MX 8M SoC. I have no idea what implementation it’s using internally, but as I wrote in the other thread, we’re planning to have some whitelisting going on, so that would solve the issue of an evil modem.


#5

@dcz Thank you so much for the response. Perhaps you could ask them what kind of controller they are using. I have opened a thread, here, on their forum. If it is ASmedia, then chances are it could have a backdoor. HP has been one of the few companies diligently working to patch these fatal flaws on their Ryzen products; https://support.hp.com/gb-en/document/c05950716 Chimera is both a hardware & software backdoor. I am not sure what kind of mitigations HP have put in place to mitigate against the hardware side of things through software work arounds, nor if they will ever, much less make it public. AMD scrubs any mention of this on their forums, along with requests for a list of OEM’s who’ve patched them, and never respond to emails either. Will you have the freedom to implement your own firmware like any OEM? and will they be working directly with you as an OEM for firmware updates?


#6

When we were auditing the hardware we plan to use for firmware requirements, the topic of USB never came up, so I don’t believe there is any that can be uploaded/modified using any documented interface.

Considering that there may be undiscovered flaws in other controllers as well, it doesn’t really matter that much what core is baked into the silicon. The proper defense is not to allow the USB interface to do unexpected things, which will be accomplished by whitelisting devices.


#7

@dcz when you say “whitelisting devices”, what do you mean, and how does this nullify any kind of hw/fw backdoor or rootkit? And how is this possible without open source FW?


#8

They provided sources in the above link, though the link to the PDF is currently broken, they are apparently DesignWare USB Controllers, which, I am assuming, is a good thing :slight_smile:


#9

Okay, I missed this part. Without it, there’s no DMA, and it doesn’t really matter whether the device or the controller is compromised, so whitelisting would do the job relatively well. But every device with DMA access is a security liability unless IOMMU is used.

How did you find the info about what i.MX 8 is using?


#10

@dcz thank you for your response. :grinning: In the link I provided above, to a discussion on their forum, from NXP https://community.nxp.com/message/1086733


#11

I looked at the datasheet myself, and it seems that all we have is a guess based on register names :confused: Perhaps looking at kernel config/sources would make it clearer.