Bug#830726: Regrabbing (was: Re: Bug#830726: xtrlock: CVE-2016-10894: xtrlock does not block multitouch events)

[Chris Lamb]

[adding x...@lists.x.org to CC, dropping t...@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,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#830726: Regrabbing(was: Re: Bug#830726: xtrlock: CVE-2016-10894: xtrlock does not block multitouch events)

[Chris Lamb]

[adding x...@lists.x.org to CC, dropping t...@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,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#830726: xtrlock: CVE-2016-10894: xtrlock does not block multitouch events

[Chris Lamb]

Hi Antoine,

> 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
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#830726: xtrlock: CVE-2016-10894: xtrlock does not block multitouch events

[Antoine Amarilli]

Hi Chris,

Thanks again for your work on this!

On Sun, Sep 08, 2019 at 09:32:20AM +0100, Chris Lamb wrote:
> 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

> > [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. ;)

> 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,

-- 
Antoine Amarilli



signature.asc
Description: PGP signature

Bug#830726: xtrlock: CVE-2016-10894: xtrlock does not block multitouch events

[Chris Lamb]

Hi Antoine,

> However, but there's still a more serious problem, which is also pretty
> weird. If I do:
[..]
>   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,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#830726: xtrlock: CVE-2016-10894: xtrlock does not block multitouch events

[Antoine Amarilli]

Hi Chris,

On Thu, Aug 22, 2019 at 11:12:52AM -0700, Chris Lamb wrote:
> > > 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.

OK makes sense.

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

OK, so I tried the patch. Initially, I got an X bad value error, but it
can apparently be fixed by initializing xi_major and xi_minor to 2. This
was done in your previous patch, is required according to man
XIQueryVersion, and appears to fix the issue.

The new patch is slightly better than the older one in that it would
seem to re-grab devices when they appear after xtrlock has been run.
This is the case both when making them disappear and reappear with
/sys/bus/usb/devices/*/authorized, and when doing the same with xinput
enable/disable. Playing with the devices after they have appeared no
longer moves the mouse pointer, whereas it did with the first patch that
you proposed.

In the case of xinput (but not the authorized file), when one plays with
the touchscreen *while* "xinput enable" runs, then I got the mouse
pointer to move to the location I was pressing on the touchscreen,
suggesting the possibility of a timing attack. In the case of the
authorized file (or when not doing either of these two things), the
mouse pointer never moves when the touchscreen is interacted with.

However, but there's still a more serious problem, which is also pretty
weird. If I do:

 (sleep 10 ; xinput 9 disable; sleep 10 ; xinput 9 enable)&
 xtrlock

Then:

- For the 10 first seconds, playing with the touchscreen does nothing
  (because it is correctly grabbed)

- For the next 10 seconds, playing with the touchscreen does nothing
  (because it is disabled)

- Then, the touchscreen seems to be "grabbed" in the sense that playing
  with the touchscreen no longer moves the mouse pointer. (Again, this
  was not true with the first version of the patch, so there's an
  improvement now.) However, the touchscreen is not "correctly" grabbed
  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.

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: if I close xtrlock by typing the correct
password, and run xtrlock again (without messing around with xinput this
time), then the touchscreen will again not be "correctly" grabbed:
playing with it does not move the mouse pointer, but I can still work
around the grab using multiple fingers. I can exit/restart xtrlock
multiple times and the problem persists.

The problem is only solved when I do an "xinput disable" and "xinput
enable" of the input while xtrlock is *not* running. Then, if I run
xtrlock afterwards, then the output is correctly grabbed and I cannot
work around it.

I'm sorry that this a bit complicated to describe... I'm not familiar at
all with what's going on, but it is as if, when the input appears while
xtrlock is running, then its attempt to grab it not only fails to work
properly (though it still prevents the mouse pointer from moving), but
also put the input in a weird state that will also make further grabs
fail to work properly, until running xinput enable/disable outside of
xtrlock puts it back in a sane state.

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

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

On Thu, Aug 22, 2019 at 11:39:47PM +0100, Matthew Vernon wrote:
> 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).

I agree we shouldn't try excessively hard, but what you describe here
isn't really an xtrlock vulnerability: xtrlock is about locking the X
display, not TTYs. Security-conscious users 

Bug#830726: xtrlock: CVE-2016-10894: xtrlock does not block multitouch events

[Matthew Vernon]

On 22/08/2019 18:50, Antoine Amarilli wrote:

Hi Chris,

On Wed, Aug 21, 2019 at 03:52:44PM -0700, Chris Lamb wrote:



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?


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


Regards,

Matthew

Bug#830726: xtrlock: CVE-2016-10894: xtrlock does not block multitouch events

[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
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#830726: xtrlock: CVE-2016-10894: xtrlock does not block multitouch events

[Chris Lamb]

Hi Antoine,

> > 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
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#830726: xtrlock: CVE-2016-10894: xtrlock does not block multitouch events

[Antoine Amarilli]

Hi Chris,

On Wed, Aug 21, 2019 at 03:52:44PM -0700, Chris Lamb wrote:
> > 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?

> 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,

-- 
Antoine Amarilli



signature.asc
Description: PGP signature

Bug#830726: xtrlock: CVE-2016-10894: xtrlock does not block multitouch events

[Chris Lamb]

Chris Lamb wrote:

> 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,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-From a4bc14b34ce924a370eabcc27c495474372497d1 Mon Sep 17 00:00:00 2001
From: Chris Lamb 
Date: Wed, 21 Aug 2019 15:26:33 -0700
Subject: [PATCH] Attempt to grab multitouch devices which are not intercepted
 via XGrabPointer. (Closes: #830726)

xtrlock did not block multitouch events so an attacker could still input
(and thus control) various programs such as Chromium, etc. via so-called
multitouch events such as pan scrolling, "pinch and zoom" or even being
able to provide regular mouse clicks by depressing the touchpad once and
then clicking with a secondary finger.

Thanks to Antoine Amarilli  for the report.

Signed-off-by: Chris Lamb 
---
 debian/control |  1 +
 debian/rules   |  4 +--
 xtrlock.c  | 69 ++
 3 files changed, 72 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 33582b1..19f88dd 100644
--- a/debian/control
+++ b/debian/control
@@ -6,6 +6,7 @@ Priority: optional
 Build-Depends:
  debhelper-compat (= 12),
  libx11-dev,
+ libxi-dev,
  x11proto-core-dev,
 Vcs-Git: https://salsa.debian.org/debian/xtrlock.git
 Vcs-Browser: https://salsa.debian.org/debian/xtrlock
diff --git a/debian/rules b/debian/rules
index 2928068..43ebe33 100755
--- a/debian/rules
+++ b/debian/rules
@@ -5,7 +5,7 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 include /usr/share/dpkg/default.mk
 -include /usr/share/dpkg/buildtools.mk
 
-CFLAGS += -DSHADOW_PWD
+CFLAGS += -DSHADOW_PWD -DMULTITOUCH
 
 ifeq (,$(findstring ^$(DEB_VERSION_UPSTREAM),^$(shell cut -d'"' -f2 patchlevel.h)))
 $(error (patchlevel.h out of sync with Debian version))
@@ -15,7 +15,7 @@ endif
 	dh $@
 
 override_dh_auto_build:
-	$(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) xtrlock.c -o xtrlock -lcrypt -lX11
+	$(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) xtrlock.c -o xtrlock -lcrypt -lX11 -lXi
 
 override_dh_fixperms:
 	dh_fixperms -X/usr/bin/xtrlock
diff --git a/xtrlock.c b/xtrlock.c
index 6117c6f..89d3a12 100644
--- a/xtrlock.c
+++ b/xtrlock.c
@@ -41,6 +41,11 @@
 #include 
 #endif
 
+#ifdef MULTITOUCH
+#include 
+#include 
+#endif
+
 #include "lock.bitmap"
 #include "mask.bitmap"
 #include "patchlevel.h"
@@ -71,6 +76,32 @@ int passwordok(const char *s) {
 #endif
 }
 
+#if MULTITOUCH
+XIEventMask evmask;
+
+/* (Optimistically) attempt to grab multitouch devices which are not
+ * intercepted via XGrabPointer. */
+void handle_multitouch(Cursor cursor) {
+  XIDeviceInfo *info;
+  int xi_ndevices;
+
+  info = XIQueryDevice(display, XIAllDevices, _ndevices);
+
+  for (int i=0; i < xi_ndevices; i++) {
+XIDeviceInfo *dev = [i];
+
+for (int j=0; j < dev->num_classes; j++) {
+  if (dev->classes[j]->type == XITouchClass &&
+  dev->use == XISlavePointer) {
+XIGrabDevice(display, dev->deviceid, window, CurrentTime, cursor,
+ GrabModeAsync, GrabModeAsync, False, );
+  }
+}
+  }
+  XIFreeDeviceInfo(info);
+}
+#endif
+
 int main(int argc, char **argv){
   XEvent ev;
   KeySym ks;
@@ -132,7 +163,32 @@ int main(int argc, char **argv){
 	program_version);
 exit(1);
   }
+
+#ifdef MULTITOUCH
+  unsigned char mask[XIMaskLen(XI_LASTEVENT)];
+  int xi_major, xi_minor, xi_opcode, xi_error, xi_event;
+
+  if (!XQueryExtension(display, INAME, _opcode, _event, _error)) {
+fprintf(stderr, "xtrlock (version %s): No X Input extension\n",
+program_version);
+exit(1);
+  }
   
+  if (XIQueryVersion(display, _major, _minor) != Success ||
+  xi_major * 10 + xi_minor < 22) {
+fprintf(stderr,"xtrlock (version %s): Need XI 2.2\n",
+program_version);
+exit(1);
+  }
+
+  evmask.mask = mask;
+  evmask.mask_len = sizeof(mask);
+  memset(mask, 0, sizeof(mask));
+  evmask.deviceid = XIAllDevices;
+  XISetMask(mask, XI_HierarchyChanged);
+  XISelectEvents(display, DefaultRootWindow(display), , 1);
+#endif
+
   attrib.override_redirect= True;
 
   if (blank) {
@@ -216,6 +272,10 @@ int main(int argc, char **argv){
 exit(1);
   }
 

Bug#830726: xtrlock: CVE-2016-10894: xtrlock does not block multitouch events

[Chris Lamb]

Hi Antoine,

> Thanks for writing the patch! I tested it on
> . For some reason it didn't
> apply cleanly to debian/rules

Mea culpa; there was another upload in the meantime that I somehow did
not spot. I have now correctly subscribed to this package in the
tracker so this shouldn't occur again.

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

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 at the moment
requiring me to restart my X session. I'm obviously doing something
wrong and I'll have another run at it ASAP.
  

Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#830726: xtrlock: CVE-2016-10894: xtrlock does not block multitouch events

[Antoine Amarilli]

Hi Chris,

Thanks for writing the patch! I tested it on
. 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


On Fri, Aug 16, 2019 at 05:46:07PM -0700, Chris Lamb wrote:
> Chris Lamb wrote:
> 
> > Patch attached that works for me on my Dell XPS 13
> 
> Antoine, does the patch attached to:
> 
>   https://bugs.debian.org/830726#43
> 
> … also work for you? If so, I will go ahead and upload.
> 
> 
> Best wishes,
> 
> -- 
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org  chris-lamb.co.uk
>`-


signature.asc
Description: PGP signature

Bug#830726: xtrlock: CVE-2016-10894: xtrlock does not block multitouch events

[Chris Lamb]

Chris Lamb wrote:

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

Antoine, does the patch attached to:

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

… also work for you? If so, I will go ahead and upload.


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#830726: xtrlock: CVE-2016-10894: xtrlock does not block multitouch events

[Chris Lamb]

tags 830726 + patch
thanks

Chris Lamb wrote:

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

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

  $ xinput --list | head -n4
  ⎡ Virtual core pointerid=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,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
From ceb73c87915ca1e976847c470be4baff3086a507 Mon Sep 17 00:00:00 2001
From: Chris Lamb 
Date: Tue, 13 Aug 2019 13:32:11 -0700
Subject: [PATCH] Attempt to grab multitouch devices which are not intercepted
 via XGrabPointer. (Closes: #830726)

xtrlock did not block multitouch events so an attacker could still input
(and thus control) various programs such as Chromium, etc. via so-called
multitouch events such as pan scrolling, "pinch and zoom" or even being
able to provide regular mouse clicks by depressing the touchpad once and
then clicking with a secondary finger.

Thanks to Antoine Amarilli  for the report.

Signed-off-by: Chris Lamb 
---
 debian/control |  1 +
 debian/rules   |  4 ++--
 xtrlock.c  | 45 +
 3 files changed, 48 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 33582b1..19f88dd 100644
--- a/debian/control
+++ b/debian/control
@@ -6,6 +6,7 @@ Priority: optional
 Build-Depends:
  debhelper-compat (= 12),
  libx11-dev,
+ libxi-dev,
  x11proto-core-dev,
 Vcs-Git: https://salsa.debian.org/debian/xtrlock.git
 Vcs-Browser: https://salsa.debian.org/debian/xtrlock
diff --git a/debian/rules b/debian/rules
index 8c6893c..9b03511 100755
--- a/debian/rules
+++ b/debian/rules
@@ -4,7 +4,7 @@ DPKG_EXPORT_BUILDFLAGS = 1
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 include /usr/share/dpkg/default.mk
 
-CFLAGS += -DSHADOW_PWD
+CFLAGS += -DSHADOW_PWD -DMULTITOUCH
 
 ifeq (,$(findstring ^$(DEB_VERSION_UPSTREAM),^$(shell cut -d'"' -f2 patchlevel.h)))
 $(error (patchlevel.h out of sync with Debian version))
@@ -14,7 +14,7 @@ endif
 	dh $@
 
 override_dh_auto_build:
-	$(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) xtrlock.c -o xtrlock -lcrypt -lX11
+	$(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) xtrlock.c -o xtrlock -lcrypt -lX11 -lXi
 
 override_dh_fixperms:
 	dh_fixperms -X/usr/bin/xtrlock
diff --git a/xtrlock.c b/xtrlock.c
index 6117c6f..389df08 100644
--- a/xtrlock.c
+++ b/xtrlock.c
@@ -41,6 +41,11 @@
 #include 
 #endif
 
+#ifdef MULTITOUCH
+#include 
+#include 
+#endif
+
 #include "lock.bitmap"
 #include "mask.bitmap"
 #include "patchlevel.h"
@@ -87,6 +92,12 @@ int main(int argc, char **argv){
 #endif
   struct timeval tv;
   int tvt, gs;
+#ifdef MULTITOUCH
+  XIEventMask evmask;
+  XIDeviceInfo *info;
+  int xi_major=2, xi_minor=2, xi_opcode, xi_error, xi_event, xi_ndevices;
+  unsigned char mask[XIMaskLen(XI_LASTEVENT)];
+#endif
 
   while (argc > 1) {
 if ((strcmp(argv[1], "-b") == 0)) {
@@ -132,7 +143,27 @@ int main(int argc, char **argv){
 	program_version);
 exit(1);
   }
+
+#ifdef MULTITOUCH
+  if (!XQueryExtension(display,INAME,_opcode,_event,_error)) {
+fprintf(stderr,"xtrlock (version %s): No X Input extension\n",
+	program_version);
+exit(1);
+  }
   
+  if (XIQueryVersion(display, _major, _minor) != Success||
+xi_major * 10 + xi_minor < 22) {
+fprintf(stderr,"xtrlock (version %s): Need XI 2.2\n",
+	program_version);
+exit(1);
+  }
+
+  evmask.mask = mask;
+  evmask.mask_len = sizeof(mask);
+  memset(mask, 0, sizeof(mask));
+  evmask.deviceid = XIAllMasterDevices;
+#endif
+
   attrib.override_redirect= True;
 
   if (blank) {
@@ -216,6 +247,20 @@ int main(int argc, char **argv){
 exit(1);
   }
 
+#ifdef MULTITOUCH
+  // (Optimistically) attempt to grab multitouch devices which are not
+  // intercepted via XGrabPointer
+  info = XIQueryDevice(display, XIAllDevices, _ndevices);
+  for (int i=0; i < xi_ndevices; i++) {
+XIDeviceInfo *dev = [i];
+for (int j=0; j < dev->num_classes; j++) {
+  if (dev->classes[j]->type == XITouchClass)
+XIGrabDevice(display, dev->deviceid, window, CurrentTime, cursor,
+ GrabModeAsync, GrabModeAsync, False, );
+}
+  }
+#endif
+
   if (fork_after) {
 pid_t pid = fork();
 if (pid < 0) {
-- 
2.23.0.rc1

Bug#830726: xtrlock: CVE-2016-10894: xtrlock does not block multitouch events

[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
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-