Ouf, long time no blog. Sorry about that. Life is.. busy these days. One of my occupations has been to defend against USB-borne attacks, as mentioned before. Probably the most known is the BadUSB attack which masquerades as a mass storage device but also is a keyboard. Then, the device would inject keystrokes which hack your machine. This class of attacks is difficult to defend against, because the operating system can hardly determine whether the user did indeed want to plug a device with those capabilities in. There is another class of attacks, though, which is a bit easier to defend against, I think. That other class is based on buggy drivers which the malicious USB device pulls in. So once you attach your device, the host’s kernel will look for the appropriate driver and let it speak with the device. That’s very convenient because it makes devices just work. However, certain drivers might not be of the same quality than others and there have indeed been cases which allow a malicious USB device to interact with a bit-rotten driver which in turn led to fatal consequences.
I have been thinking a lot about how to defend against either class of attacks. You can easily come up with various solutions based on pop-ups interrupting the user and authoring the device before it will be ready for use. Or with a policy-based solution that requires you to generate a firewall-like description of what the machine is allowed to do. Or a mixture of those two attempts. And that’s what has been done, already. Arguably, none of these solutions has been successful, as I am not aware of any built-in protection scheme for any major operating system. The reason, I believe, is that users expect things to just work and once you make it not work, users get grumpy. So the challenge is to unfold protection capabilities without changing the users’ experience.
The short version of our approach is that we are trying to be smart about the user’s intent. That is, if the screen is locked, then we block the device. If a new keyboard is present and it tries to perform “dangerous” actions, we block them. Of course, you may very well expect that device to work when the screen is locked or the new keyboard to perform actions deems dangerous. This is why is make sure you have a way to opt out of the mechanism and continue to enjoy your GNOME experience. Almost all credits go to Ludovico for coming up with a set of patches as well as following up to make sure we can get it merged. Our slides are here and the video of our presentation is here:
But I wanted to write more about GUADEC… This year’s GUADEC was in Thessaloniki, Greece, and I had the pleasure to be talking about the above mentioned protection. It was the end of the summer so the city was nicely warm and comfy. The coffee, juices, pastries, and other food and drinks in small shops on the streets were amazingly fresh and yummie. Arriving in Thessaloniki was okay. I’ve had better airport transfers in my life, but since there were only two buses it was hard to get lost. I needed to pay attention to the GPS, though, to find my right stop. It’s been long since I’ve slept in a bunk bed, but because we’re all GNOME people we had a good time.
The conference had a few interesting talks which can be followed on the recordings page. I enjoyed watching Daiki presenting about plans and ideas for managing credentials in a sandboxed world, Benzo talking about user sessions with systemd, and the (not recorded) one by Giannis on the impact of the GDPR. Of course, the 45 minutes or so we had for discussing all the facets of the GDPR were too short and I think that I would have focussed on other aspects such as choosing an appropriate legitimate ground, transfer to non-member states, or dealing with requests from data subjects. But it’s been a good introduction and I am happy to see non-technical topics at the conference.
Meeting friends, old and new, is really good and I have had a fantastically efficient time talking to people. It’s so much better to meet in-person and talk directly rather than via email or bug tracker.
