Hacker News Reader

Comment by ljd | Hacker News Reader

But when that keyboard gets plugged into the motherboard of the laptop, it'll have an opportunity to install malware in the form of device drivers.

View on HN

Worse: laptop keyboards are usually connected to a special embedded firmware (IIRC on my Clevo laptop it's called EC, short for embedded controller), which handles the FN+x key combos like LCD brightness, volume control, keyboard backlight (Lenovo!), WiFi/BT/cellphone-data connectivity, webcam enabling (!) and other detailed functions.

Now, if this EC chip is vulnerable, a malicious keyboard can have direct DMA access (just like FireWire controllers, EC is usually connected to the main PCI bus)... no need for drivers here.

>direct DMA access

Direct direct memory access access?

Financed with a withdrawal from the ATM machine, of course.

Laptop keyboards are directly connected to embedded controller primarily because they are completely passive switch matrices (and EC includes - often directly in hardware - logic for scanning keyboard matrix), so there is nothing meaningful to exploit on the EC side.

Also connecting EC directly to some PCI bus does not make much sense from both system design and cost perspectives. Usual place to connect EC to is LPC, which is explicitly designed for such devices (things on motherboard like serial/parallel/game ports, TPM, FDC, keyboard controller/EC, BIOS flash and various ). Random review of datasheets found by google seems to indicate that chips that are only embedded controllers and do not contain additional ISA based peripherals (like ISA DMA controller itself) tend to not even implement the pin required for LPC DMA/bus master transactions (as it is not required for anything in normal operation).

Hold a second, BIOS flash? /me smells #badBIOS

As per my other post, the keyboard is most likely a PS2 keyboard interface (physical or emulated) connected to a simple PS2/LPC(ISA) bus interface inside the EC. It will literally deliver an IRQ to that bus (IRQ 1) at which point the EC has to suck down a character from the keyboard buffer and do something with it.

It's not clever, can't use DMA and generally is the dumbest thing in the entire machine.

If they somehow manage to work around it I'd eat a box of lightbulbs. It's hard enough to coerce it to work to start with.

Source: I used to design embedded PC kit from the board level.

Thanks for the clarification!

But one question remains: how does the EC control stuff like the bluetooth radio and webcams? They're USB devices to the OS, so in theory there should be a USB hub inside the EC?

Not necessarily. It may only have power control function. If you pull a USB device out it's the same as turning it off in theory and vice versa. It's probably just turning the device off or setting it into standby mode.

edit to add: some Intel south bridges have integrated EC which makes things a little uncertain.

I don't believe HIDs have the ability to install arbitrary drivers. Windows will try to identify the device and locate the driver via Windows Update, or use a generic HID driver. Or the OEM may have preinstalled drivers.

In any case, a malicious keyboard can simulate keypresses and pwn your machine that way. No evil driver needed.

If a laptops FN keys work in BIOS/UEFI, does it even matter?

See other post about embedded firmware and DMA.

In any case, a malicious keyboard can simulate keypresses and pwn your machine that way. No evil driver needed.

Indeed: https://hakshop.myshopify.com/collections/usb-rubber-ducky/p...

Actually no. The keyboard is still an old fashioned PS2 device on the majority of laptops. It connects to the LPC bus (low pin count - similar to ISA) via a PS2/ISA bridge in the embedded controller. It's just like in an oooooold AT PC. There is no possibility for it to deliver anything but keystrokes. It doesn't go anywhere near the USB stack and can't inject devices or play with the HID drivers.

Connection-wise it looks like this:

http://i.imgur.com/ayFybSd.png

Keystrokes can be dangerous on their own but engineering a solution to this that assumes the correct state of the machine and can operate software is unlikely simply due to the margin of error.

Reply on news.ycombinator.com