Thunderbolt Access Security Implications

Overview

Thunderbolt 3 is an upcoming I/O technology that will likely take over as the preferred method of attaching various external devices such as displays, storage devices and others. Unlike USB, TB allows wide access to devices or memory for example. It is speculated that a malicious device could be attached to a PC and copy memory or inject malicious spyware. This has been successfully achieved in the past, over a similar I/O port, Firewire.

Possible scenarios

  1. A notebook attached to a projector at a conference. While providing the display capabilities, the malicious device also starts making copy of the hardrive in the background.
  2. While you leave a notebook in the office, somebody attaches a malicious device to copy data over

User Experience Considerations

Similar to a firewall approach, it would be undesirable to treat every device as potentially harmful in a general case. It renders a machine broken by default. The "do you allow new TB device?" authorization model that is used on Windows offloads the responsibility to authorize a device to the user who might not have experience and enough context to make such decision. It will simply create a hurdle that users will habituate to skip through. An "unbreak my computer" dialog.

Permissive Permissions Model

Asking a generic "Do you trust Foobar Inc. Device?" is a simple transfer of responsibility/blame to the user. It doesn't provide specifics of what the device is trying to do. To authorize a device, it should be known what the device is about to do. Rather than asking yes/no authorization questions, specific action by the user could be requested instead. When plugging in a projector, the system could present the display settings panel in presentation mode, requiring explicit enabling of the detected projector. See https://wiki.gnome.org/Design/SystemSettings/Displays

Unless we can prevent the projector to also access system memory or storage devices, a broad device blocking and user driven whitelisting will not be effective against the attack described above.

Operation Modes

The Thunderbolt technology does allow to be used in three modes, limiting the access scope. The primary mode is the native TB3 with the direct access to everything (and highest achievable transfer speeds). In addition the technology is able to operate in USB 2 and 3 mode and Display Port mode. Additionally a DP + USB mode is possible.

Security Modes

It is possible to define a security policy for TB devices at BIOS level. When any attached TB device gets recognized the mode is referred to as 'NONE'. 'DP only' is a security mode where only display port devices (displays and projectors) get recognized. 'USER' is a mode when unknown devices need to be authorized by the user and thier UUID is stored to be used next time without explicit authorization. 'SECURE' is the strictest model where in addition to device identity their authenticity is checked using crypto hashing.

All the use cases below assume systems are configured to run in the SECURE mode.

Feedback

Activating Thunderbolt can take up to 10 seconds. While it would be desirable to speed up the discovery and security handshake, it's necessary to provide feedback to the user that the hardware is in an intermediate state, similar to connecting to wifi network.

https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/shell/thunderbolt-init.png

Typical Scenario

A typical home user running distributions such as Fedora or Ubuntu.

  • automatically enable new TB3 devices:
    • when the user is administrator
    • a session is running (computer isn't locked)

Locked Session

To address attack scenario [2], when connecting a previously unknown device, when the session is locked the device is *not* authenticated and a notification is triggered. Once unlocked, the notification hints to reconnect the device to allow it to function properly. Similar notification is triggered when the device is attached before booting the system. New devices require the system to be authorized and running.

https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/shell/thunderbolt-reattach.png

Multi-user environments

When a user is not an administrator, a typical situation for corporate environments, new devices are not automatically athorized to be used. Instead a notification is triggered to take you the settings panel is opened to allow to authenticate as a system administrator and explicitly authorize a device. However in corporate environment, it's more likely to be done remotely using the *boltctl* utility.

https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/system-settings/thunderbolt/thundebolt-noadmin.png

Paranoid Mode

To lower the risk of malicious devices when traveling, the TB3 could switch to a less capable but safer DisplayPort/USB mode. I would personally refrain from exposing the BIOS security modes described above. Instead a full/restricted access setting can address the 'paranoid traveller' use case.

https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/system-settings/thunderbolt/thundebolt.png

Empty State

While I would generally recommend not exposing things to configure when hardware is not present, we currently show an empty state for a system with no Bluetooth controller, so we should remain consistent with that behavior. Apart from TB3 missing completely, the user may have chosed to set disable the direct access in the BIOS in which case the empty state can communicate the situation and provide a link to the documentation explaining the USB/DP fallback BIOS settings.

https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/system-settings/thunderbolt/empty-state.png

Discussion

Resources

Design/Whiteboards/ThunderboltAccess (last edited 2018-04-03 11:13:05 by JakubSteiner)