Bug 341469

Summary:	Not grabbing secondary mouse pointers allows password to be typed through to other windows
Product:	[Unmaintained] ksmserver	Reporter:	Kyle Mills <khonspam>
Component:	lockscreen	Assignee:	David Edmundson <kde>
Status:	RESOLVED FIXED
Severity:	normal	CC:	mgraesslin
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	openSUSE
OS:	Linux
Latest Commit:	http://commits.kde.org/plasma-workspace/23b6cfb14457063eb8121f97c2d5371b7e8fe3ed	Version Fixed In:	5.3.0
Sentry Crash Report:

Description Kyle Mills 2014-12-01 18:59:43 UTC

This simply needs an XI2 update. (XGrabPointer → XIGrabDevice loop)
It's a security issue, as the user can accidentally send their password over a chat system or any other unsecured window.

Reproducible: Always

Steps to Reproduce:
1. Plug in two mice, two keyboards, set them up as two mouse pointers using xinput
2. Focus the second mouse on a window
3. Use the first mouse to lock the screen
4. "Accidentally" type your password using the second keyboard
5. Unlock the screen using the first keyboard

Actual Results:  
6. Realize your password was received by the window focused by the second mouse
4b.Typing on the second keyboard has no effect on the password prompt

Expected Results:  
No window still having focus while the screenlock is active, any keyboard typing into the password prompt (focused by all on start)

Focusing the window with the first mouse and locking the screen with the second doesn't leak the password, because the screenlock grabs the first mouse away from the window, and the second mouse was already focused on the taskbar menu.

Comment 1 Martin Flöser 2015-02-19 13:10:37 UTC

Git commit 23b6cfb14457063eb8121f97c2d5371b7e8fe3ed by Martin Gräßlin.
Committed on 13/02/2015 at 09:36.
Pushed by graesslin into branch 'master'.

[screenlocker] Also grab XInput2 devices

With XInput2 it's possible that multiple pairs of keyboard and pointers
are connected. As the lock screen only grabbed keyboard and pointer using
the core protocol any additional input devices were still reporting
input events to non-lockscreen windows creating the risk of interaction
with the system and accidentially typing a password where it doesn't
belong.

This change ensures that all additional master devices are also grabbed.
Unfortunately there are no xcb bindings for xinput2 (considered
experimental and thus not build on at least all debian based distros)
and because of that the XLib library is used. This brings some problems
as we cannot process the events (for that we would need xcb bindings,
to get the events). To still be able to get any keyboard and mouse events
we grab using the core protocol as it used to be and then ignore the
"Virtual core" devices and don't grab them with XInput2. Input events
from additional devices are grabbed and ignored, but definately no longer
delivered to other windows.
FIXED-IN: 5.3.0
REVIEW: 122558

M  +2    -0    CMakeLists.txt
M  +4    -1    config-X11.h.cmake
M  +4    -0    ksmserver/screenlocker/CMakeLists.txt
M  +90   -1    ksmserver/screenlocker/ksldapp.cpp
M  +1    -0    ksmserver/screenlocker/ksldapp.h

http://commits.kde.org/plasma-workspace/23b6cfb14457063eb8121f97c2d5371b7e8fe3ed