Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1231403 > unrolled thread

Bug#1094998: steam-devices: should document the security trade-offs implied by installing this package

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1094998: steam-devices: should document the security trade-offs implied by installing this package Simon McVittie <smcv@debian.org> - 2025-02-02 13:30 +0100
    Bug#1094998: steam-devices: should document the security trade-offs implied by installing this package Fabian Greffrath <fabian@greffrath.com> - 2025-02-03 08:50 +0100
      Bug#1094998: steam-devices: should document the security trade-offs implied by installing this package Simon McVittie <smcv@debian.org> - 2025-02-03 12:00 +0100
        Bug#1094998: steam-devices: should document the security trade-offs implied by installing this package Fabian Greffrath <fabian@greffrath.com> - 2025-02-03 12:10 +0100

#1231403 — Bug#1094998: steam-devices: should document the security trade-offs implied by installing this package

Package: steam-devices
Version: 1:1.0.0.82~ds-3
Severity: wishlist
Tags: help
X-Debbugs-Cc: fabian@debian.org, pere@hungry.com
Control: block 1094936 by -1
Control: block 1078751 by -1

If packages outside the Valve/Steam ecosystem are going to install
steam-devices automatically (#1094936) or encourage it to be installed
(#1078751) then it should have documentation describing the trade-off
between functionality and security that it implies.

I am "too close" to this package to write that documentation: I don't know
where prospective users of this package would look for this information
(README.Debian? the Description? Appstream metadata, if added by #1078751?)
and I don't know how to condense the details of its security tradeoffs into
a short summary.

Below is an attempt at the long version, with the benefits and risks of
each thing that it enables. I would appreciate it if someone else could
condense this into a summary.

    smcv

/dev/uinput
===========

When I say "local user" or "locally logged-in user" in all of the below,
I mean a user who was, at the time, authenticated as physically present
at the system console.

steam-devices makes /dev/uinput available to locally logged-in users via
udev's uaccess mechanism. /dev/uinput allows user-space programs to
generate mock input devices such as keyboards, mice and game controllers,
which will control programs in the same way as real keyboards and mice.

The benefit is that this is used by two (or possibly more) features of
the proprietary Steam client. Steam Input takes gamepad actions as input,
and generates a mock keyboard, mouse and Xbox 360 controller, which can be
used to control games that do not normally support gamepads, or games that
support only Xbox-compatible gamepads but not Playstation or Nintendo.

Similarly, Steam Remote Play takes input actions from the same Steam
account's session on a mobile device app or another PC, and similarly
generates a mock local keyboard, mouse and game controller; this combines
with video and audio streaming in the opposite direction to form a
specialized gaming-oriented remote desktop protocol, so that players
can run a game on a powerful PC but interact with it on a smaller or
more convenient device.

The security risk is that a malicious local user can open the /dev/uinput
file descriptor, and then keep it open in a background process after they
have logged out or performed "fast user switching". After another local
user logs in, the attacker's emulated keyboard and mouse will provide
input to the victim's desktop session, which they could use to enter
malicious commands.

A mitigation to this security risk is that the victim can see this input
happening, and the attacker cannot see what they are doing (they must
control the victim's desktop "blindly" by predicting what effect their
input will have).

Gamepads in raw HID mode
========================

steam-devices makes /dev/hidraw* devices that correspond to an assortment
of known gamepads available to locally logged-in users. These include
popular gamepads from Microsoft (Xbox), Sony (Playstation), Nintendo
(Switch, etc.) and Valve (Steam Controller and the Steam Deck's built-in
gamepad), along with various third-party "clone" gamepads compatible
with those. /dev/hidraw* are equivalent to the level of access to these
gamepads that would be provided on Windows, and possibly also macOS.

The benefit is that raw HID access allows low-level access to controller
functionality that is not exposed by the higher-level evdev interface,
like Nintendo Switch controllers' motion controls, reconfiguring gamepads
for different modes or behaviours, and updating gamepad firmware.

The security risk is that a malicious local user can open the /dev/hidraw*
file descriptor, and then keep it open in a background process after
they have logged out or performed "fast user switching". After another
local user logs in, the attacker can read whatever input that user
performs via the game controller (like a strange sort of keylogger),
reconfigure it for different modes or behaviours, or potentially change
its behaviour by reprogramming its firmware.

A mitigation to this security risk is that it is uncommon to enter
secret input such as passwords with a gamepad, except for perhaps
via an on-screen virtual keyboard, which would require the attacker
to reconstruct the positions of the virtual keys that were pressed by
observing gamepad movements; so this is less powerful for the attacker
than a keylogger (its scope is more like a mouse logger).

Virtual reality and XR devices
==============================

steam-devices makes a few devices represending virtual reality and XR
peripherals available to locally logged-in users.

The benefit is that this access allows SteamVR to make use of these
devices, including updating their firmware in some cases.

Again, the security risk is that a malicious local user can open the
device file descriptor, and then keep it open in a background process
after they have logged out or performed "fast user switching". After
another local user logs in, the attacker can continue to read input from
the device and/or write configuration and potentially firmware to it.

-- 

[toc] | [next] | [standalone]

#1231526

Hi Simon,

Am 2025-02-02 13:23, schrieb Simon McVittie:
> If packages outside the Valve/Steam ecosystem are going to install
> steam-devices automatically (#1094936) or encourage it to be installed
> (#1078751) then it should have documentation describing the trade-off
> between functionality and security that it implies.
> 
> I am "too close" to this package to write that documentation: I don't 
> know
> where prospective users of this package would look for this information
> (README.Debian? the Description? Appstream metadata, if added by 
> #1078751?)
> and I don't know how to condense the details of its security tradeoffs 
> into
> a short summary.
> 
> Below is an attempt at the long version, with the benefits and risks of
> each thing that it enables. I would appreciate it if someone else could
> condense this into a summary.

thank you very much for the elaboration, it was a fun read! I guess your 
expertice on this topic is unmatched by most other developers.

I think the long version of the risk documentation that you provided 
below would fit perfectly into README.Debian, though I agree that a 
TL/DR version would be nice to have as well. This should be accompanied 
by a short reference in the package description such as "Installing this 
package may impose some security risks that are discussed in detail in 
/usr/share/doc/steam-devices/README.Debian." The downside of this 
approach is, of course, that the documentation will only be available 
once the package is already installed.

But, to be honest, if you already share your computer hardware and 
access at the system console with a malicious user, there may be way 
more obvious ways to get attacked than through the steam-devices 
package, right?

Cheers,

  - Fabian

[toc] | [prev] | [next] | [standalone]

#1231561

On Mon, 03 Feb 2025 at 08:45:25 +0100, Fabian Greffrath wrote:
> But, to be honest, if you already share your computer hardware and access at
> the system console with a malicious user, there may be way more obvious ways
> to get attacked than through the steam-devices package, right?

Well, yes. The most obvious one is that with physical access to the
computer, they can insert a hardware keylogger, or reboot into live
media, or any other "physical presence required" attack.

The part of this that concerns me most is /dev/uinput, which you likely
don't actually need if you aren't running Steam (but it's a requirement
for increasingly many Steam features, so steam-devices definitely does
need to provide access to it).

I think concerns about reprogramming a game controller with malicious
firmware are particularly overblown, because if the attacker has
physical access to it, they can ... already do that, by plugging it into
a different computer! (Game controllers being a notably portable category
of device.) But it's something that was treated as a showstopper by some
of the systemd team when, with my $day_job hat on, I tried to upstream
a subset of this into udev.

What I want to avoid is adding a Recommends (or possibly Suggests) to
SDL as you suggested, and then finding that a year or two later I'm being
required to spend large amounts of high-priority time on dealing with
someone reporting this as a security vulnerability, and demanding my
immediate attention and/or resignation.

    smcv

[toc] | [prev] | [next] | [standalone]

#1231562

> What I want to avoid is adding a Recommends (or possibly Suggests) to
> SDL as you suggested, and then finding that a year or two later I'm 
> being
> required to spend large amounts of high-priority time on dealing with
> someone reporting this as a security vulnerability, and demanding my
> immediate attention and/or resignation.

Sure, I fully understand that.

But it would still help to mention in the package description the names 
of the two most prominent game controllers that this packages adds 
support for. This would have saved me a lot of googling (and rejecting a 
lot of ill-sounding and outdated advice on this way), just to end up 
with the exact same conclusion: install the steam-devices package.

Thanks!

  - Fabian

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web