Bug#830726: xtrlock does not block multitouch events

[Antoine Amarilli]

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
locked.

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]

Hi,

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?)


Regards,

[Antoine Amarilli]

Hi Chris,

I can still reproduce this. I just booted an USB key with a live Debian
stable image from
https://cdimage.debian.org/debian-cd/current-live/amd64/bt-hybrid/debian-live-10.0.0-amd64-standard.iso.torrent
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
xtrlock.

[Chris Lamb]

severity 830726 + important
thanks

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.


Regards,

[Salvatore Bonaccorso]

Control: tags 830726 + security
Control: retitle 830726 xtrlock: CVE-2016-10894: xtrlock does not block multitouch events

Hi,

This issue has been assigned CVE-2016-10894.

Regards,
Salvatore

[Chris Lamb]

severity 830726 grave
tags 830726 + security
retitle 830726 xtrlock: CVE-2016-10894: xtrlock does not block multitouch events
thanks

Hi,

The following vulnerability was published for xtrlock.

CVE-2016-10894[0]:
| xtrlock through 2.10 does not block multitouch events. Consequently,
| an attacker at a locked screen can send input to (and thus control)
| various programs such as Chromium via events such as pan scrolling,
| "pinch and zoom" gestures, or even regular mouse clicks (by depressing
| the touchpad once and then clicking with a different finger).

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-10894
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-10894


Regards,

[Chris Lamb]

tags 830726 + patch
thanks

Post by Chris Lamb
| xtrlock through 2.10 does not block multitouch events. Consequently,
| an attacker at a locked screen can send input to (and thus control)
| various programs such as Chromium via events such as pan scrolling,
| "pinch and zoom" gestures, or even regular mouse clicks (by depressing
| the touchpad once and then clicking with a different finger).

Patch attached that works for me on my Dell XPS 13:

$ xinput --list | head -n4
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ ELAN25B5:00 04F3:25B5 id=12 [slave pointer (2)]
⎜ ↳ DELL07E6:00 06CB:76AF Touchpad id=13 [slave pointer (2)]

(The second in this list is my multitouch touchscreen device.)


Regards,

[Antoine Amarilli]

Hi Chris,

Thanks for writing the patch! I tested it on
<https://salsa.debian.org/debian/xtrlock.git>. For some reason it didn't
apply cleanly to debian/rules, but it did apply fine to xtrlock.c and I
manually added -DMULTITOUCH to debian/rules to enable it.

So, the patch works fine on my machine. All input from the touchscreen
seems to be blocked (in particular touching the touchscreen no longer
moves the mouse cursor with the lock icon).

However, I think I see a problem with the patch's design. If I
understand correctly, the patch makes xtrlock grab all devices
initially. But if the attacker plugs in a new device after xtrlock is
started (e.g., an USB multitouch trackpad), then it wouldn't be grabbed,
right?

I can't try out this exact scenario because I don't have such a USB
device, and I can't easily disconnect my laptop's touchscreen. However,
I have tried blocking the touchscreen by writing 0 to
/sys/bus/usb/devices/3-1.5/authorized (the touchscreen then disappears
from the output of xinput). If I run "sleep 10 ; echo 1 | sudo tee
authorized" in the background and run xtrlock (to simulate plugging in
the touchscreen after 10 seconds), then sure enough, once the
touchscreen is "plugged" it is not grabbed by xtrlock and the initial
problem still occurs.

Of course the patch is already a big improvement, but do you have any
idea about how to address this problem with new devices being plugged in
while xtrlock is running?

Best,
--
Antoine Amarilli

Post by Chris Lamb
Patch attached that works for me on my Dell XPS 13

https://bugs.debian.org/830726#43

 also work for you? If so, I will go ahead and upload.
Best wishes,
--
,''`.
: :' : Chris Lamb
`-

[Chris Lamb]

I've been working on an updated patch that detects new devices and
blocks them too. However, "grabbing" devices during the processing of
these "device hierarchy changed" events appears to do something funny
and actually disables all input entirely for me

Whilst I've fixed that bit at least, the new attached patch doesn't
grab devices that are renabled via "xinput enable" although we do
successfully detect that "edge" event now.

That is to say:

$ [find id via xinput list]
$ (xinput disable 10; sleep 10; xinput enable 10) &
$ ./xtrlock

... does not then block multitouch events subsequent to the sleep and
"xinput enable" call.

Antoine, how did you find the right /sys/bus/usb/devices/FOO directory?
I'm only using xinput as I can't seem to locate my touchpad under
/sys/bus. (Perhaps we don't need to care about the "xinput enable" case)


Best wishes,

[Antoine Amarilli]

Hi Chris,

Post by Chris Lamb

I've been working on an updated patch that detects new devices and
blocks them too. However, "grabbing" devices during the processing of
these "device hierarchy changed" events appears to do something funny
and actually disables all input entirely for me

Whilst I've fixed that bit at least, the new attached patch doesn't
grab devices that are renabled via "xinput enable" although we do
successfully detect that "edge" event now.

Cool! I'm not sure whether this other edge case is important -- are
there situations where an attacker in front of a locked computer could
manage to pull this off?

Oh, and if we can detect the edge event, can't we grab the devices
somehow -- in the worst case, just by restarting xtrlock?

Another question (but that's probably being too paranoid): with
approaches that grab new devices as they show up, are there risks of a
timing attack where the attacker could be able to do some events before
xtrlock can grab the device? (Probably not as a human, but imagining a
malicious device that would regularly simulate disconnections.) The
question is, does xtrlock have any guarantee that it can grab the device
before events from the device will be processed?

Post by Chris Lamb
Antoine, how did you find the right /sys/bus/usb/devices/FOO directory?
I'm only using xinput as I can't seem to locate my touchpad under
/sys/bus.

Well, pretty clumsily. I did "lsusb -t -v". I found the touchscreen
there, with its ID (04f3:000a). Then I did something like:

cd /sys/bus/usb/devices
for a in *; do
echo $a;
cat $a/idVendor
done

... and went to the folder having the right ID -- and tried to disable
it and saw that I had found the right one.

Best,

[Chris Lamb]

Hi Antoine,

Post by Antoine Amarilli

Post by Chris Lamb
Whilst I've fixed that bit at least, the new attached patch doesn't
grab devices that are renabled via "xinput enable" although we do
successfully detect that "edge" event now.

Cool! I'm not sure whether this other edge case is important -- are
there situations where an attacker in front of a locked computer could
manage to pull this off?

An attacker being able to run xinput? No we should not care about that
but I was _only_ using that to *emulate* your example of plugging in a
USB multitouch device, not caring about that particular vector per se.

Unfortunately, it turns out my touchpad is a PCI device and I can't
thus follow the exact same testcase as you (ie. via the "authorized")
file. Not only that when I try and emulate it using "rmmod i2c_hid &&
sleep 5 && modprobe i2c_hid" I cannot reproduce that the device is not
regrabbed.

I wonder; could you try the patch I attached previously and see
whether that actually works for USB devices? If so, I would be happy
with rolling it out. If it does not appear to work, please could you
add a quick:

fprintf(stderr, "grabbing\n");

… at the top of the the handle_multitouch function and see whether
that's even called when it gets re-enabled?


Regards,

[Chris Lamb]

Hi Matthew,

I think we may be in danger of Trying Too Hard here - xtrlock and
similar are already vulnerable to some attacks (e.g. Ctrl-Alt-F1 could
get you to do tty which might have a login session on).

Sure, but plugging in an external multitouch USB pointer seems like
something that would want to try a few moments to avoid... (ignore
that I'm using "xinput" per se)


Regards,

[Chris Lamb]

Hi Antoine,

However, but there's still a more serious problem, which is also pretty

[..]

because I can still work around the grab using multiple fingers (i.e.,
press somewhere, then interact with chromium). This is exactly like
the bug I reported in the original xtrlock, with the only difference
that the mouse pointer does not move while I do it.

I can partly reproduce this, as well as some other strange behaviour
upon "plugging in" a device that, like your descriptions, are quite involved
to explain!

So the regrab doesn't actually solve things. What is even weirder is
that this problem with the screen not being "correctly" grabbed will
persist on future xtrlock runs

[…]

Can you reproduce this pretty weird behavior? Does it make any sense to
you?

I did once actually but I think I dismissed it as some kind of weird
errant process or just an issue as I was doing lot of recompilation,
etc. etc. Hmpf.

[The exact same behavior seems to occur if I replace xinput
enable/disable with the corresponding play with the authorized file.]

I am pleased that we can also get the same behaviour using xinput vs
"authorized" as I would have more confidence that the latter emulates
Eve plugging in a external USB device versus xinput in terms of
abstraction layers.

I'm a little stuck on how to proceed code-wise so my next steps are to
contact the maintainers of the Input Extension and see if they have
any insight.


Regards,

[Antoine Amarilli]

Hi Chris,

Thanks again for your work on this!

Post by Chris Lamb
I can partly reproduce this, as well as some other strange behaviour
upon "plugging in" a device that, like your descriptions, are quite involved
to explain!

So the regrab doesn't actually solve things. What is even weirder is
that this problem with the screen not being "correctly" grabbed will
persist on future xtrlock runs

[
]

Can you reproduce this pretty weird behavior? Does it make any sense to
you?

I did once actually but I think I dismissed it as some kind of weird
errant process or just an issue as I was doing lot of recompilation,
etc. etc. Hmpf.

Glad that you can reproduce these weird problems and confirm that I not
alone in seeing them. ;-P

Post by Chris Lamb

[The exact same behavior seems to occur if I replace xinput
enable/disable with the corresponding play with the authorized file.]

I am pleased that we can also get the same behaviour using xinput vs
"authorized" as I would have more confidence that the latter emulates
Eve plugging in a external USB device versus xinput in terms of
abstraction layers.

Agreed, plus as the latter doesn't work for you it would have been more
complicated to figure things out. ;)

Post by Chris Lamb
I'm a little stuck on how to proceed code-wise so my next steps are to
contact the maintainers of the Input Extension and see if they have
any insight.

This sounds like a good idea -- also I wonder if the weird behavior
"xtrlock persistently puts an input in a strange state" doesn't reveal a
bug someplace else...

As this is getting a bit open-ended, though, do you think it could be
worth it to release one of these patches soon (the first one, or the
second one with the missing initializations I pointed out) as a first
step that fixes the vulnerability at least when Eve cannot plug in new
devices?

Best,

[Chris Lamb]

Hi Antoine,

Post by Antoine Amarilli
As this is getting a bit open-ended, though, do you think it could be
worth it to release one of these patches soon

I agree, but I will first write to the xinput2 maintainers and leave a
little time to get a response there. However, I will set myself a
rough timeout of 3/4 days from right now so that we fallback to a
previous iteration as you outline regardless of whether I get around
to this or they fruitfully reply.


Regards,

[Chris Lamb]

[adding ***@lists.x.org to CC, dropping ***@security.debian.org; please retain all CCs]

Dear Xorg developers,

[…]

I recently became a co-maintainer for the xtrlock screen locking
utility. As part of this, I noticed a bug report filed by Antoine
Amarilli which points out that so-called multitouch events are not
blocked when xtrlock is enabled:

https://bugs.debian.org/830726

This means that some applications (notably Chromium) can still be
controlled even when the machine is locked down.

When I looked at the code and the documentation regarding multitouch
events, this was "to be expected" due to it only calling the
XGrabPointer function. I therefore extended the code to enumerate over
all multitouch devices and lock them too via XIGrabDevice as part of
the version 2 of the X Input Extensions:

https://bugs.debian.org/830726#43

However, Antoine then pointed out that this would not prevent an
attacker plugging in such a multitouch device *after* xtrlock has
been started and thus permit controlling the desktop. I thus revised
the patch to detect the introduction of the new device via the
XI_HierarchyChanged event:

https://bugs.debian.org/830726#65

This appeared to work initially but we were seeing some strange
behaviour where the touchscreen is not "correctly" grabbed; one can
still work around the grab using multiple fingers (eg. press
somewhere, then interact with Chromium) but some even weirder
behaviour whereby grabs will persist *after* the xtrlock process has
ended! For more detail about this, please see:

https://bugs.debian.org/830726#90

I would be interested in your input here. Hopefully I am doing
something obviously bogus which you will be able to point out for a
quick and easy fix but I have a gut feel something deeper is awry
given that locks persist beyond the end of the process.


Best wishes,

[Antoine Amarilli]

Hi Chris,

Thanks for fixing this and pushing it! Is the final fix also supposed to
address the case of an attacker plugging in a new USB multitouch device?
or is it just the latest patch I had tested (with the weird quirks when
a new device appears)?

If the latter -- should this be pointed out as a known limitation or
vulnerability of the package?

Best,
--
Antoine Amarilli

This is an automatic notification regarding your Bug report
#830726: xtrlock: CVE-2016-10894: xtrlock does not block multitouch events
Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
replying to this email.
--
830726: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830726
Debian Bug Tracking System
Date: Fri, 11 Oct 2019 19:52:58 +0000
Subject: Bug#830726: fixed in xtrlock 2.12
Source: xtrlock
Source-Version: 2.12
We believe that the bug you reported is fixed in the latest version of
xtrlock, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
Format: 1.8
Date: Fri, 11 Oct 2019 12:41:39 -0700
Source: xtrlock
Architecture: source
Version: 2.12
Distribution: unstable
Urgency: medium
Closes: 830726
xtrlock (2.12) unstable; urgency=medium
.
* CVE-2016-10894: Attempt to grab multitouch devices which are not
intercepted via XGrabPointer. (Closes: #830726)
* Bump Standards-Version to 4.4.1.
9a78849e65046057a84e060b9f2c03a571de6fb8 1602 xtrlock_2.12.dsc
90fde89622bd85ad2454de1308b10499b66f00e3 20620 xtrlock_2.12.tar.xz
4e69677968fc27410bed3b0b54a0945c65a9948f 6187 xtrlock_2.12_amd64.buildinfo
21c9bb1a25121afc7adbd1e96694a8390544e09437d296e83a96b6245f88aa7f 1602 xtrlock_2.12.dsc
13b634dc6c23a35386e683163d2b8be76de2229e1cd7fb82517cb8e388e278ba 20620 xtrlock_2.12.tar.xz
f645e51a15122f1767f25d2580bab930aa248740be79d9a941caf674c9f3207a 6187 xtrlock_2.12_amd64.buildinfo
5966c685ad31b3b00fa85d674c490eb7 1602 x11 optional xtrlock_2.12.dsc
49adf9b39eed6ea717462f5171da5a30 20620 x11 optional xtrlock_2.12.tar.xz
79be2ba64b7d7d76096b3028a2aacc88 6187 x11 optional xtrlock_2.12_amd64.buildinfo
Date: Sun, 10 Jul 2016 16:18:41 -0400
Subject: xtrlock does not block multitouch events
X-Mailer: reportbug 6.6.6
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).
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.
The pinch and zoom is taken into account by chromium even though the session is
locked.
The event should not be seen by chromium while the session is locked.
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)
ii libc6 2.22-13
ii libx11-6 2:1.6.3-1
xtrlock recommends no packages.
xtrlock suggests no packages.
-- debconf-show failed

[Antoine Amarilli]

Hi Chris,

Post by Antoine Amarilli
Thanks for fixing this and pushing it! Is the final fix also supposed to
address the case of an attacker plugging in a new USB multitouch device?

Alas not; I received no input from upstream after repeated pings so I
pushed ahead.

Alright -- too bad.

Post by Antoine Amarilli
If the latter -- should this be pointed out as a known limitation or
vulnerability of the package?

https://salsa.debian.org/debian/xtrlock/commit/0254c8652b415263bebadbe1413e71b9ec12e741.diff
... but I would concede that is not very visible.

Sorry I'm not too sure of what you mean, what is it that you wrote about
known limitations in
<https://salsa.debian.org/debian/xtrlock/commit/0254c8652b415263bebadbe1413e71b9ec12e741.diff>?
I see nothing, unless you mean the source code comment?

In principle I would think there ought to be some kind of record
(besides the discussion on this bug report) that the problem isn't
really fixed. But to be honest I don't care too much personally as I'm
migrating from X to wayland so phasing out xtrlock on my machines. And
it's already great you could push out that fix which addresses most of
the concerns.

Best,

[Chris Lamb]

Hi Antoine,

<https://salsa.debian.org/debian/xtrlock/commit/0254c8652b415263bebadbe1413e71b9ec12e741.diff>?

Post by Antoine Amarilli
I see nothing, unless you mean the source code comment?

Yes, the source code comment. I've expanded the (released) changelog
entry here:

https://salsa.debian.org/debian/xtrlock/commit/34e6c7c6c33ce6b7510172a2e05e710a99fdc146

… so this visibility will be in subsequent releases at the very least.


Regards,

[Chris Lamb]

Hi Antoine,

Looks great! There's a grammar problem "This fix does not the situation"
but it doesn't matter.

Whoops, fixed in:

https://salsa.debian.org/debian/xtrlock/commit/e578040d4bedf81874cc2bf1c62d6643b36b527d


Regards,

[Antoine Amarilli]

Looks good to me! Thanks again for all your work on this.

Best,
--
Antoine Amarilli

Post by Chris Lamb
Hi Antoine,

Looks great! There's a grammar problem "This fix does not the situation"
but it doesn't matter.

https://salsa.debian.org/debian/xtrlock/commit/e578040d4bedf81874cc2bf1c62d6643b36b527d
Regards,
--
,''`.
: :' : Chris Lamb
`-