[IgorBog61650384]

I love the idea but is scaring me a bit security wise. This can be a really hidden persistence method for malware.

Imagine the following scenario - memory only malware lands on my computers, identifies the keyboard, uploads a malicious firmware and disappears. Using basic heuristics like time and entropy it detect when I logon to the machine, get my passwords, understands my OS, and what for a hidden signal by the memory only malware. If the signal is not detected for a while because I rebooted my computer or reinstalled it, It unlocks the computer with the password at a time of inactivity, and types in a command like wget/curl to to download the malware again, and so on.

I think this can even be used for Virtual Machine escape, as many VMs just pass-through HID commands, so its possible the firmware can be updated from a VM.

Kudos to System76 though for providing the firmware, this helps in auditing it and running tools like lint or PVS studio to decrease the chance of bugs like that. They are consistent in being open source and I hope more vendors with firmware follow their lead.

[tzarc]

QMK requires a RESET keycode to be added to your keymap in order to reboot into firmware update mode while it's running. Alternatively, depending on the configured options at compile-time, you can either hold ESC as you plug it in, or hold Space+B.

system76's launch requires the holding of ESC on bootup (well, top-left matrix position).

Under normal circumstances there's no "unattended update" functionality built in. Unsure if system76 has modified this behaviour to do so.

(Full disclosure, am a QMK maintainer)

[sigprof]

Unfortunately, system76 developers added exactly that functionality to their firmware: https://github.com/system76/qmk_firmware/commit/a1ab70c3a28a...

So it is possible to reboot into the firmware update mode just by sending some bytes to the raw HID interface. Apparently they did not think about the security aspect of this feature.

[jackpot51]

Would you mind creating a GitHub issue to track this on? We may decide to change the behavior before production

EDIT: I have created an issue here: https://github.com/system76/launch/issues/17

We do not intend for the production firmware to include any software reset to bootloader functionality. It will require a physical keypress (Fn+ESC)

[jackpot51]

There is an automatic reset to bootloader feature that will be removed prior to production, customer units will always require a physical keypress (Fn+ESC) in order to flash firmware: https://github.com/system76/launch/issues/17

[PurpleFoxy]

There is a pretty simple solution for this, require physical input to enter firmware upload mode.

Most open source keyboards have a button you press to switch from KB mode to flash target mode. Not sure how this laptop works but a solution would be to require the user to hold fn and some other key for a few seconds before it will accept firmware.

This problem btw is actually present in a lot of devices you already use but it’s proprietary. People have found out ways to flash firmware to USB devices, SD cards and hard drives before. It just requires reverse engineering to work it out.

[IgorBog61650384]

You're right, as long as the hardware switch is really hardware and not fake-hardware-implemented-in-software like many vendors.

[wiml]

That's a real risk but closing the design doesn't really mitigate it, famously: https://semiaccurate.com/2009/07/31/apple-keyboard-firmware-...

[meepmorp]

They didn't write the firmware. QMK is a popular open source keyboard firmware.

And fwiw, user updatable keyboards are usually configured require a particular key be pressed to flash it, or have a dedicated button to hit with a paper clip.

[userbinator]

I'm not too fond of the idea of having the firmware updatable in-place either, but given that the board picture shows it has an ISP header, you could probably disable the self-updating functionality and then you would need to do firmware modifications physically.