Re: Have I caught a firmware attack in the act? Or am I just paranoid?
On Tue, Aug 13, 2019 at 3:30 PM Rebecca N. Palmer wrote:
> but at least some USB flash drives instead use an SCSI command ,
> which usbguard won't catch.
This seems like a significant missing feature, but I guess it would
require a fair bit of Linux kernel work to support filtering such
> I'm also not sure whether firmware-based malware is common enough to be
> something the average developer should worry about.
IMO proprietary software is worrisome in any context and the Linux
kernel definitely needs hardening against malicious devices. There has
been some recent work on exploiting radio firmware and then exploiting
Linux from there, here are two examples that come to mind:
> Aug 5 07:21:51 rnpalmer-laptop kernel: [34901.758084] usb 3-2.1:
> SerialNumber: F32402A6
This got deleted.
> Aug 6 21:52:26 rnpalmer-laptop kernel: [50370.579113] usb 3-2.1: New
> USB device found, idVendor=058f, idProduct=1234
This vendor/product combo is known to usb.ids:
/usr/share/misc/usb.ids:058f Alcor Micro Corp.
/usr/share/misc/usb.ids: 1234 Flash Drive
/usr/share/misc/usb.ids: 6387 Flash Drive
/usr/share/misc/usb.ids: 9380 Flash Drive
/usr/share/misc/usb.ids: 9381 Flash Drive
/usr/share/misc/usb.ids: 9382 Acer/Sweex Flash drive
> Aug 6 21:52:26 rnpalmer-laptop kernel: [50370.579117] usb 3-2.1: New
> USB device strings: Mfr=1, Product=2, SerialNumber=0
The serial number went to zero.
> Aug 6 21:52:26 rnpalmer-laptop kernel: [50370.579121] usb 3-2.1:
> Manufacturer: Alcor Micro
This changed from "Generic" and idVendor=058f is Alcor Micro.
Based on the serial number deletion, I'd speculate that some internal
part of the flash holding details about the device identity
malfunctioned, so the firmware reverted back to the default hardcoded
product id for Alcor flash drives. No idea if this is a reasonable
theory or what caused the malfunction, malware or otherwise.