A friend of mine is very into keyboards and, after seeing his keyboards at work and admiring his Ergodox many times, I took the plunge and built my own. 152 solder joints later, I have this beauty:

It took a few days to get used to it and in the process, I found a bug in layer switching, which I contributed a fix for. While fixing it, I came across some very cool debugging features - the keyboard has a console which gives debug info and is very easy to connect to:

screen /dev/tty.usbmodem1A12144

This console gives a lot of debugging information, and it turns out that it can show every key press! Neat, until you realize that any user of the system can also see every single key press. A non-privileged test user on my Mac ¹ was able to read every key press I made while typing as my normal user.

This is a huge breach of security. I routinely create accounts on my desktop for other people (my fiancée, my friends who are learning to code), so this is simply an unacceptable risk. This is present in keyboards built with custom firmware, but also on the firmware that ships with the keyboard or is downloaded from the online configuration tool.

Fortunately, the firmware was created to be pretty modular, and it is easy to turn this functionality on or off by adding just a few define guards:

#if defined(DEBUG)
// Enable CLI
CLI_init();
#endif

// ...

#if defined(DEBUG)
// Process CLI
CLI_process();
#endif

What this does is turn off initialization and processing of the CLI. It is still there, sitting in the background - and there might still be more security risks with it - but the obvious attack vector is gone.

On October 10, 2016, I submitted an issue to address this, and a corresponding pull request. Following a discussion with Haata (the maintainer of the firmware), we decided to pursue adding an option to have a security-hardened mode, as well as adding a passcode to enable to console on non-hardened keyboards.

My personal recommendation is to apply my patch to your firmware if you are using OS X². On Linux, you shouldn't have to patch anything immediately, since accessing the console requires sudo permissions.

Stay posted for more updates! I hope to have the first pass at the security-hardened mode out during October, and hopefully the corresponding configurator changes can follow shortly after.

+++

¹ I verified the issue exists on OS X, but it does not exist in Linux since you need root access to access the console. However, the documentation suggests adding a udev rule file which does give read permissions to everyone without sudo, so many Linux users are likely vulnerable. ² You can get the patch from my pull request, it works and is only closed because it is not the long-term solution. I'm using it myself for now. If you need help, email me or tweet at me.