GNOME Security Internship - The end?
Here you can find the introduction, the update 1, the update 2, the update 3, the update 4 and the update 5.
The end? Is the internship already ended?
Yes, incredibly these three months went by so fast. It was an awesome experience, so I’d like to thank the whole GNOME Foundation for giving me this opportunity.
What’s the project status?
The first part regarding protecting the system from potentially unwanted new USB devices can be considered completed. Probably now it will requires just bug fixing and minor changes, if necessary. The required merge requests are up.
The second part regarding limiting the number of usable keys for untrusted keyboards reached a working stage. However it’s still under evaluation which is the best way to achieve it, because even if with the current solution works it doesn’t mean that this is the desirable way to do it.
What will happen from tomorrow?
Even if the internship will be officially ended I’m still pledged to carry on these two features until they’ll be merged in upstream.
Right now I’m actively searching for a job (preferably in the open source world), so in the next few days I’ll still be able to spend a considerable amount of time in this project, at least until I find a full time job.
GNOME Control Center USB protection switch
Old:
New:
As I mentioned in the last blog post we realized that the always on USB protection was marginally better (or worse) than the protection with lock screen. So we decided to leave in Control Center only an on/off switch that by default controls the USB lock screen protection.
If necessary it’s still possible to enable the always on protection editing the usb-protection-level desktop schema.
This UI change allowed us to remove the ambiguous protection on switch with the drop down protection level “never block”.
Now when you disable the protection from Control Center, in USBGuard we set InsertedDevicePolicy to apply-policy and we add an allow everything in the rules file. In this way we try to leave USBGuard in a clean state. From there USBGuard will never block USB devices anymore. You are then free to leave it as is or, if you want a stringent or different protection behaviour, use a third parties GUI or even write your own script to handle USBGuard.
Limit untrusted USB keyboards
Finally in this front we reached a first working implementation.
In the new Control Center tab we show an on/off switch and a list of currently plugged in keyboards. This list is automatically updated when keyboards gets added or removed.
We store the authorization property with hwdb. In this way we can bound it to a specific device product and retrieve this information directly from libinput.
When a new keyboard is added it is limited by default until you manually set it to be fully trusted.
While this implementation is working as expected, we are currently evaluating other alternatives.
For example in mutter every time we receive a new keystroke we check if it is a dangerous key.
As an alternative we could use the kernel EVIOCSMASK instead.
Another thing that we are evaluating is if we should replace the hwdb with another db created ad-hoc for this purpose.
What to expect next and comments
In a couple of weeks I’ll return hopefully with a few interesting updates regarding the untrusted USB keyboards.
Feedback is welcome!
Comments
Jens
To help me understand the level of protection offered by this: How do keyboards get identified? Would it be enough for a malicious device to have the same vendor ID and product ID as a keyboard that’s trusted by the user? Since AFAIK these IDs are quite easy to fake, that would mean that this feature couldn’t protect against a targeted attack (where the attacker has enough information about the victim). But of course it would still protect against other kinds of attacks.
Ludovico
@Jens for the general USB protection (the first part of this project where new USB devices get rejected if the lock screen is active) we use the identification mechanism offered by USBGuard. That means that we use the vendor id, the product id, the device name and the device serial.
For the keyboard protection we currently just use the vendor id and the product id (because if we use the hwdb we are unable to fit also the serial for example, but this may change if we stop using hwdb).
Anyway keep in mind that with USB devices is impossible to reliably identify them because when a new device is plugged in we can’t verify if it is telling us the truth or not. Also the serial value is not even always useful. For example in my USB Keyboard the serial is just the keyboard model name, nothing remotely unique.
So to answer your question, we can protect users against generic attacks but if, for example, you know the specific vendor and model that your victim is using you’ll still be able to craft a malicious USB device that mimics the already authorized device.
The situation will hopefully improve with the recently announced new cryptographic authentication offered with USB Type-C.
Jens
@Ludovico: Thanks!
Leave a Comment
Your email address will not be published. Required fields are marked *