Bug#830726: xtrlock does not block multitouch events
Add Reply
Antoine Amarilli
2016-07-10 20:30:02 UTC
Package: xtrlock
Version: 2.8
Severity: normal
Tags: upstream

Dear Maintainer,

xtrlock appears not to block multitouch events when the session is locked, so
that any user stumbling upon a locked session can still input multitouch events.

One could imagine that this could constitute a security vulnerability (requiring
physical access to the machine).

Steps to reproduce (on a computer with a suitably configured touchscreen):

1. Open chromium (my example of a program that processes multitouch events) and
put it in fullscreen mode.
2. Check that you can pinch and zoom (put two fingers of the screen and move
them closer or further apart to change the zoom level).
3. Run xtrlock to lock the session.
4. With xtrlock running, put one finger on the screen and leave it there (the
mouse pointer with the xtrlock lock icon follows that finger). While doing this,
perform the pinch and zoom with two other fingers.

Observed result:

The pinch and zoom is taken into account by chromium even though the session is

Expected result:

The event should not be seen by chromium while the session is locked.

-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (650, 'testing'), (600, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xtrlock depends on:
ii libc6 2.22-13
ii libx11-6 2:1.6.3-1

xtrlock recommends no packages.

xtrlock suggests no packages.

-- debconf-show failed
Chris Lamb
2019-07-21 18:40:01 UTC
Post by Antoine Amarilli
The pinch and zoom is taken into account by chromium even
though the session is locked.
I cannot reproduce this. (Can you still?)

: :' : Chris Lamb
`. `'` ***@debian.org / chris-lamb.co.uk
Antoine Amarilli
2019-08-10 00:00:01 UTC
Hi Chris,

I can still reproduce this. I just booted an USB key with a live Debian
stable image from
on the affected hardware (Lenovo IdeaPad Yoga 13 with an ELAN
touchscreen). It booted to a TTY, so I apt-get installed xserver-xorg,
openbox, slim, chromium, xtrlock, started a graphical session, and I
could reproduce the problem: run chromium, run xtrlock, press one finger
on the screen (the mouse pointer with the padlock icon moves to that
finger), then interact with chromium with the other fingers.

The problem is not actually limited to multitouch events in Chromium
(i.e., not just pinch and zoom), as I can e.g. minimize chromium by
tapping the minimize icon with the second finger while the first finger
"holds" the xtrlock icon, and generally interact with the chromium
interface (though not all interface elements work, for some reason).

I can only see this problem with chromium; I cannot interact with other
windows (e.g., xterm, firefox) in this way. This may be linked to the
fact that the chromium window is not decorated, i.e., it does not have
the openbox decorations.

Are you sure you tried to reproduce it with multiple fingers as above?
Are you sure you are using a touchscreen with multitouch support?

Now that I notice this is not limited to multitouch events, this looks
to me like a genuine vulnerability affecting xtrlock when such hardware
is present (or can be plugged in): an attacker can, e.g., completely
mess around with the chromium settings while the session is "locked" by
Antoine Amarilli
Chris Lamb
2019-08-11 13:10:02 UTC
severity 830726 + important

Hi Antoine,
I can still reproduce this. I just booted an USB key with […]
Sorry, I did not automatically receive your reply. In addition,
perhaps I missed the bit about the multitouch *touchscreen* — I can
now reproduce this on my Dell XPS 13.

Elevating the severity for the time being whilst I investigate more.

: :' : Chris Lamb
`. `'` ***@debian.org 🍥 chris-lamb.co.uk