Bug 1197466 (CVE-2022-27817) - AUDIT-FIND: CVE-2022-27817: swhkd: Input Events are Consumed For all Keyboard Input Devices in all Sessions
Summary: AUDIT-FIND: CVE-2022-27817: swhkd: Input Events are Consumed For all Keyboard...
Status: NEW
Alias: CVE-2022-27817
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Security (show other bugs)
Version: Current
Hardware: Other Other
: P5 - None : Normal (vote)
Target Milestone: ---
Assignee: Aakash Sen Sharma
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 1196890
  Show dependency tree / graph
 
Reported: 2022-03-24 09:38 UTC by Matthias Gerstner
Modified: 2022-04-14 08:51 UTC (History)
4 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Gerstner 2022-03-24 09:38:44 UTC 
+++ This bug was initially created as a clone of Bug #1196890

This is to track issue 2.e) in the parent bug:

  ## 2.e) Input Events are Consumed For all Keyboard Input Devices in all Sessions

  The daemon listens for input events on uinput device level. This means even
  other users in other sessions or on the text mode consoles will be affected by
  this. In theory this fact could be used to log passwords and other sensitive
  information from other users. However, recognized hotkey events will be
  discarded by the daemon i.e. the keys seemingly no longer work for regular
  keys. Therefore it is more like a local DoS for other users.

Suggested Fix:

  ## 3.c) Establish a systemd Session Context

  I'm not completely sure about issue 2.e). I think it is possible to determine
  the current session the unprivileged user has via systemd. Then the daemon
  should Pause itself as soon as the active session is changed to another one,
  and reactivate itself once the original user session becomes active again.

See also bug 1196890 comment 13 for a follow-up discussion of this topic.