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

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Antoine Amarilli <a3nm@a3nm.net>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: xtrlock does not block multitouch events

Date: Sun, 10 Jul 2016 16:18:41 -0400

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

Message #10 received at 830726@bugs.debian.org (full text, mbox, reply):

From: "Chris Lamb" <lamby@debian.org>

To: 830726@bugs.debian.org

Cc: "Antoine Amarilli" <a3nm@a3nm.net>

Subject: Re: xtrlock does not block multitouch events

Date: Sun, 21 Jul 2019 15:36:23 -0300

Hi,

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

I cannot reproduce this. (Can you still?)


Regards,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org / chris-lamb.co.uk
       `-

Message #15 received at 830726@bugs.debian.org (full text, mbox, reply):

From: Antoine Amarilli <a3nm@a3nm.net>

To: 830726@bugs.debian.org

Subject: Re: xtrlock does not block multitouch events

Date: Sat, 10 Aug 2019 01:36:17 +0200

[Message part 1 (text/plain, inline)]

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.

-- 
Antoine Amarilli

[signature.asc (application/pgp-signature, inline)]

Message #20 received at 830726@bugs.debian.org (full text, mbox, reply):

From: "Chris Lamb" <lamby@debian.org>

To: "Antoine Amarilli" <a3nm@a3nm.net>, 830726@bugs.debian.org

Subject: Re: xtrlock does not block multitouch events

Date: Sun, 11 Aug 2019 14:01:18 +0100

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,

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

Message #27 received at 830726@bugs.debian.org (full text, mbox, reply):

From: Salvatore Bonaccorso <carnil@debian.org>

To: Antoine Amarilli <a3nm@a3nm.net>, 830726@bugs.debian.org

Subject: Re: Bug#830726: xtrlock does not block multitouch events

Date: Fri, 16 Aug 2019 06:16:00 +0200

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

Message #36 received at 830726@bugs.debian.org (full text, mbox, reply):

From: "Chris Lamb" <lamby@debian.org>

To: 830726@bugs.debian.org

Cc: "Antoine Amarilli" <a3nm@a3nm.net>, team@security.debian.org

Subject: Re: xtrlock: CVE-2016-10894: xtrlock does not block multitouch events

Date: Fri, 16 Aug 2019 08:21:26 -0700

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

Message #43 received at 830726@bugs.debian.org (full text, mbox, reply):

From: "Chris Lamb" <lamby@debian.org>

To: 830726@bugs.debian.org

Cc: "Antoine Amarilli" <a3nm@a3nm.net>, team@security.debian.org

Subject: Re: xtrlock: CVE-2016-10894: xtrlock does not block multitouch events

Date: Fri, 16 Aug 2019 08:27:20 -0700

[Message part 1 (text/plain, inline)]

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

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org / chris-lamb.co.uk
       `-

[0001-Attempt-to-grab-multitouch-devices-which-are-not-int.patch (text/x-patch, attachment)]

Message #50 received at 830726@bugs.debian.org (full text, mbox, reply):

From: "Chris Lamb" <lamby@debian.org>

To: 830726@bugs.debian.org

Cc: "Antoine Amarilli" <a3nm@a3nm.net>, team@security.debian.org

Subject: Re: xtrlock: CVE-2016-10894: xtrlock does not block multitouch events

Date: Fri, 16 Aug 2019 17:46:07 -0700

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

Message #55 received at 830726@bugs.debian.org (full text, mbox, reply):

From: Antoine Amarilli <a3nm@a3nm.net>

To: Chris Lamb <lamby@debian.org>

Cc: 830726@bugs.debian.org, team@security.debian.org

Subject: Re: xtrlock: CVE-2016-10894: xtrlock does not block multitouch events

Date: Sun, 18 Aug 2019 12:09:23 +0200

[Message part 1 (text/plain, inline)]

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


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

[signature.asc (application/pgp-signature, inline)]

Message #60 received at 830726@bugs.debian.org (full text, mbox, reply):

From: "Chris Lamb" <lamby@debian.org>

To: "Antoine Amarilli" <a3nm@a3nm.net>

Cc: 830726@bugs.debian.org, team@security.debian.org

Subject: Re: xtrlock: CVE-2016-10894: xtrlock does not block multitouch events

Date: Tue, 20 Aug 2019 14:09:21 -0700

Hi Antoine,

> 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

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

Message #65 received at 830726@bugs.debian.org (full text, mbox, reply):

From: "Chris Lamb" <lamby@debian.org>

To: "Chris Lamb" <lamby@debian.org>, "Antoine Amarilli" <a3nm@a3nm.net>

Cc: 830726@bugs.debian.org, team@security.debian.org

Subject: Re: xtrlock: CVE-2016-10894: xtrlock does not block multitouch events

Date: Wed, 21 Aug 2019 15:52:44 -0700

[Message part 1 (text/plain, inline)]

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

[0001-Attempt-to-grab-multitouch-devices-which-are-not-int.patch (text/x-patch, attachment)]

Message #70 received at 830726@bugs.debian.org (full text, mbox, reply):

From: Antoine Amarilli <a3nm@a3nm.net>

To: Chris Lamb <lamby@debian.org>

Cc: 830726@bugs.debian.org, team@security.debian.org

Subject: Re: xtrlock: CVE-2016-10894: xtrlock does not block multitouch events

Date: Thu, 22 Aug 2019 19:50:41 +0200

[Message part 1 (text/plain, inline)]

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 (application/pgp-signature, inline)]

Message #75 received at 830726@bugs.debian.org (full text, mbox, reply):

From: "Chris Lamb" <lamby@debian.org>

To: "Antoine Amarilli" <a3nm@a3nm.net>

Cc: 830726@bugs.debian.org, team@security.debian.org

Subject: Re: xtrlock: CVE-2016-10894: xtrlock does not block multitouch events

Date: Thu, 22 Aug 2019 11:12:52 -0700

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

Message #80 received at 830726@bugs.debian.org (full text, mbox, reply):

From: "Chris Lamb" <lamby@debian.org>

To: "Matthew Vernon" <matthew@debian.org>, "Antoine Amarilli" <a3nm@a3nm.net>, 830726@bugs.debian.org

Cc: team@security.debian.org

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

Date: Thu, 22 Aug 2019 16:00:12 -0700

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

Message #85 received at 830726@bugs.debian.org (full text, mbox, reply):

From: Matthew Vernon <matthew@debian.org>

To: Antoine Amarilli <a3nm@a3nm.net>, 830726@bugs.debian.org, Chris Lamb <lamby@debian.org>

Cc: team@security.debian.org

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

Date: Thu, 22 Aug 2019 23:39:47 +0100

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

Message #90 received at 830726@bugs.debian.org (full text, mbox, reply):

From: Antoine Amarilli <a3nm@a3nm.net>

To: Chris Lamb <lamby@debian.org>, Matthew Vernon <matthew@debian.org>

Cc: 830726@bugs.debian.org, team@security.debian.org

Subject: Re: xtrlock: CVE-2016-10894: xtrlock does not block multitouch events

Date: Fri, 23 Aug 2019 22:19:30 +0200

[Message part 1 (text/plain, inline)]

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 should know that TTYs exist
out of the X session, and wouldn't leave a logged-in session in a TTY.
By contrast, problems with multitouch are xtrlock failing to do its job.

Best,

-- 
Antoine Amarilli

[signature.asc (application/pgp-signature, inline)]

Message #95 received at 830726@bugs.debian.org (full text, mbox, reply):

From: "Chris Lamb" <lamby@debian.org>

To: "Antoine Amarilli" <a3nm@a3nm.net>, "Matthew Vernon" <matthew@debian.org>

Cc: 830726@bugs.debian.org, team@security.debian.org

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

Date: Sun, 08 Sep 2019 09:32:20 +0100

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

Message #100 received at 830726@bugs.debian.org (full text, mbox, reply):

From: Antoine Amarilli <a3nm@a3nm.net>

To: Chris Lamb <lamby@debian.org>

Cc: Matthew Vernon <matthew@debian.org>, 830726@bugs.debian.org, team@security.debian.org

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

Date: Sun, 8 Sep 2019 12:14:25 +0200

[Message part 1 (text/plain, inline)]

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 (application/pgp-signature, inline)]

Message #105 received at 830726@bugs.debian.org (full text, mbox, reply):

From: "Chris Lamb" <lamby@debian.org>

To: "Antoine Amarilli" <a3nm@a3nm.net>

Cc: "Matthew Vernon" <matthew@debian.org>, 830726@bugs.debian.org, team@security.debian.org

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

Date: Sun, 08 Sep 2019 16:11:45 +0100

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

Message #110 received at 830726@bugs.debian.org (full text, mbox, reply):

From: "Chris Lamb" <lamby@debian.org>

To: "Chris Lamb" <lamby@debian.org>, "Antoine Amarilli" <a3nm@a3nm.net>, "Matthew Vernon" <matthew@debian.org>

Cc: 830726@bugs.debian.org, xorg@lists.x.org

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

Date: Tue, 10 Sep 2019 12:47:11 +0100

[adding xorg@lists.x.org to CC, dropping team@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
     `. `'`      lamby@debian.org 🍥 chris-lamb.co.uk
       `-

Message #115 received at 830726@bugs.debian.org (full text, mbox, reply):

From: "Chris Lamb" <lamby@debian.org>

To: "Chris Lamb" <lamby@debian.org>, "Antoine Amarilli" <a3nm@a3nm.net>, "Matthew Vernon" <matthew@debian.org>

Cc: 830726@bugs.debian.org, xorg@lists.x.org

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

Date: Sun, 22 Sep 2019 16:03:56 +0100

[adding xorg@lists.x.org to CC, dropping team@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
     `. `'`      lamby@debian.org 🍥 chris-lamb.co.uk
       `-

Message #120 received at 830726-close@bugs.debian.org (full text, mbox, reply):

From: Chris Lamb <lamby@debian.org>

To: 830726-close@bugs.debian.org

Subject: Bug#830726: fixed in xtrlock 2.12

Date: Fri, 11 Oct 2019 19:52:58 +0000

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
have further comments please address them to 830726@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Chris Lamb <lamby@debian.org> (supplier of updated xtrlock package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Fri, 11 Oct 2019 12:41:39 -0700
Source: xtrlock
Architecture: source
Version: 2.12
Distribution: unstable
Urgency: medium
Maintainer: Matthew Vernon <matthew@debian.org>
Changed-By: Chris Lamb <lamby@debian.org>
Closes: 830726
Changes:
 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.
Checksums-Sha1:
 9a78849e65046057a84e060b9f2c03a571de6fb8 1602 xtrlock_2.12.dsc
 90fde89622bd85ad2454de1308b10499b66f00e3 20620 xtrlock_2.12.tar.xz
 4e69677968fc27410bed3b0b54a0945c65a9948f 6187 xtrlock_2.12_amd64.buildinfo
Checksums-Sha256:
 21c9bb1a25121afc7adbd1e96694a8390544e09437d296e83a96b6245f88aa7f 1602 xtrlock_2.12.dsc
 13b634dc6c23a35386e683163d2b8be76de2229e1cd7fb82517cb8e388e278ba 20620 xtrlock_2.12.tar.xz
 f645e51a15122f1767f25d2580bab930aa248740be79d9a941caf674c9f3207a 6187 xtrlock_2.12_amd64.buildinfo
Files:
 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

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEwv5L0nHBObhsUz5GHpU+J9QxHlgFAl2g2y8ACgkQHpU+J9Qx
HlglMw/8DZoBlobJZYBH/wdojjimjSblfiVpQr9WuvYQ53gEIHp7tRNYWgUfkLoP
p6s5TWDfyxhio15l7fqLp2J/8WG5WlW86SYqraarpDNHbftl/D1OTtTE+LpPW09a
rQKIIqS/sOJ7y5ta47hFtP8n4IahASz+g4xmvUkEz1564FQD5Qy6w1zH5ChV8CKv
8FUyPISa3igAenplGPnygNY/T1ZBsQsh2v5bdIwyiuC2JRN8cxU8eXiZ91xPCrdn
FWGQrebAYoESKFJD4Zw/gOg2XSodNNADbJeZ01bvEBlIuRdbgxVbH48RtDLHf6Uq
MCxx/Il8i82Pqd4HEeCEG1B+Spcug/jO5aVdoCe+u1y+h2eo31cdSRiiaN7LUmlo
vXdcieGG6M/+l7Ch2fzo+WmjvqhIG4bFBwWBz686Q8+aIDk2q7WpqBWBNJB9lAm5
kwtb7n6J3VeGyeR9a0s2GkkIcglTswaRqDjKoXf28BmN4q/DrHorHMvK/OWd7a7c
MJib06k0/Jw8srGiVx5jwicMG6qF7NvrHYy/9M3jGHFh1tDd6t+X8VPDFvwklB6f
sCW0woakdEX2ChAu3Kvx5GbYyD8zE8NjNjyz6WfzgP/FMwrO+7dE4Bdu+TNIlbDC
AnpMkYIDtMErW5iXKpA3FEJKx6o5WXPv8BDe6d2UKU855SlIMqI=
=0ysM
-----END PGP SIGNATURE-----

Message #125 received at 830726@bugs.debian.org (full text, mbox, reply):

From: Antoine Amarilli <a3nm@a3nm.net>

To: 830726@bugs.debian.org

Subject: Re: Bug#830726 closed by Chris Lamb <lamby@debian.org> (Bug#830726: fixed in xtrlock 2.12)

Date: Sat, 12 Oct 2019 15:02:11 +0200

[Message part 1 (text/plain, inline)]

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



On Fri, Oct 11, 2019 at 07:57:03PM +0000, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the xtrlock package:
> 
> #830726: xtrlock: CVE-2016-10894: xtrlock does not block multitouch events
> 
> It has been closed by Chris Lamb <lamby@debian.org>.
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Chris Lamb <lamby@debian.org> by
> replying to this email.
> 
> 
> -- 
> 830726: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830726
> Debian Bug Tracking System
> Contact owner@bugs.debian.org with problems

> Date: Fri, 11 Oct 2019 19:52:58 +0000
> From: Chris Lamb <lamby@debian.org>
> To: 830726-close@bugs.debian.org
> Subject: Bug#830726: fixed in xtrlock 2.12
> Message-Id: <E1iJ0yA-000FXj-57@fasolo.debian.org>
> 
> 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
> have further comments please address them to 830726@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
> 
> Debian distribution maintenance software
> pp.
> Chris Lamb <lamby@debian.org> (supplier of updated xtrlock package)
> 
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmaster@ftp-master.debian.org)
> 
> 
> Format: 1.8
> Date: Fri, 11 Oct 2019 12:41:39 -0700
> Source: xtrlock
> Architecture: source
> Version: 2.12
> Distribution: unstable
> Urgency: medium
> Maintainer: Matthew Vernon <matthew@debian.org>
> Changed-By: Chris Lamb <lamby@debian.org>
> Closes: 830726
> Changes:
>  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.
> Checksums-Sha1:
>  9a78849e65046057a84e060b9f2c03a571de6fb8 1602 xtrlock_2.12.dsc
>  90fde89622bd85ad2454de1308b10499b66f00e3 20620 xtrlock_2.12.tar.xz
>  4e69677968fc27410bed3b0b54a0945c65a9948f 6187 xtrlock_2.12_amd64.buildinfo
> Checksums-Sha256:
>  21c9bb1a25121afc7adbd1e96694a8390544e09437d296e83a96b6245f88aa7f 1602 xtrlock_2.12.dsc
>  13b634dc6c23a35386e683163d2b8be76de2229e1cd7fb82517cb8e388e278ba 20620 xtrlock_2.12.tar.xz
>  f645e51a15122f1767f25d2580bab930aa248740be79d9a941caf674c9f3207a 6187 xtrlock_2.12_amd64.buildinfo
> Files:
>  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
> From: Antoine Amarilli <a3nm@a3nm.net>
> To: Debian Bug Tracking System <submit@bugs.debian.org>
> Subject: xtrlock does not block multitouch events
> Message-ID: <146818192189.12824.5554238893763808868.reportbug@gamma.a3nm.net>
> 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).
> 
> 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

[signature.asc (application/pgp-signature, inline)]

Message #130 received at 830726@bugs.debian.org (full text, mbox, reply):

From: "Chris Lamb" <lamby@debian.org>

To: "Antoine Amarilli" <a3nm@a3nm.net>, 830726@bugs.debian.org

Subject: Re: Bug#830726: closed by Chris Lamb <lamby@debian.org> (Bug#830726: fixed in xtrlock 2.12)

Date: Sat, 12 Oct 2019 19:13:05 -0000

Hi Antoine,

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

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

Indeed. I did write that here:

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

... but I would concede that is not very visible. I think I was
subconciously hoping that a deeper fix will be forthcoming.


Regards,

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

Message #135 received at 830726@bugs.debian.org (full text, mbox, reply):

From: Antoine Amarilli <a3nm@a3nm.net>

To: Chris Lamb <lamby@debian.org>

Cc: 830726@bugs.debian.org

Subject: Re: Bug#830726: closed by Chris Lamb <lamby@debian.org> (Bug#830726: fixed in xtrlock 2.12)

Date: Mon, 14 Oct 2019 11:31:38 +0200

[Message part 1 (text/plain, inline)]

Hi Chris,

On Sat, Oct 12, 2019 at 07:13:05PM -0000, Chris Lamb wrote:
> > 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.

> > If the latter -- should this be pointed out as a known limitation or
> > vulnerability of the package?
> 
> Indeed. I did write that here:
> 
>   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,

-- 
Antoine Amarilli

[signature.asc (application/pgp-signature, inline)]

Message #140 received at 830726@bugs.debian.org (full text, mbox, reply):

From: "Chris Lamb" <lamby@debian.org>

To: "Antoine Amarilli" <a3nm@a3nm.net>

Cc: 830726@bugs.debian.org

Subject: Re: Bug#830726: closed by Chris Lamb <lamby@debian.org> (Bug#830726: fixed in xtrlock 2.12)

Date: Mon, 14 Oct 2019 19:13:05 -0000

Hi Antoine,

<https://salsa.debian.org/debian/xtrlock/commit/0254c8652b415263bebadbe1413e71b9ec12e741.diff>?
> 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
     `. `'`      lamby@debian.org 🍥 chris-lamb.co.uk
       `-

Message #145 received at 830726@bugs.debian.org (full text, mbox, reply):

From: Antoine Amarilli <a3nm@a3nm.net>

To: Chris Lamb <lamby@debian.org>

Cc: 830726@bugs.debian.org

Subject: Re: Bug#830726: closed by Chris Lamb <lamby@debian.org> (Bug#830726: fixed in xtrlock 2.12)

Date: Tue, 15 Oct 2019 08:12:11 +0200

[Message part 1 (text/plain, inline)]

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

Best,

-- 
Antoine Amarilli


On Mon, Oct 14, 2019 at 07:13:05PM -0000, Chris Lamb wrote:
> Hi Antoine,
> 
> <https://salsa.debian.org/debian/xtrlock/commit/0254c8652b415263bebadbe1413e71b9ec12e741.diff>?
> > 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
>      `. `'`      lamby@debian.org 🍥 chris-lamb.co.uk
>        `-

[signature.asc (application/pgp-signature, inline)]

Message #150 received at 830726@bugs.debian.org (full text, mbox, reply):

From: "Chris Lamb" <lamby@debian.org>

To: "Antoine Amarilli" <a3nm@a3nm.net>

Cc: 830726@bugs.debian.org

Subject: Re: Bug#830726: closed by Chris Lamb <lamby@debian.org> (Bug#830726: fixed in xtrlock 2.12)

Date: Wed, 16 Oct 2019 00:57:16 -0000

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,

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

Message #155 received at 830726@bugs.debian.org (full text, mbox, reply):

From: Antoine Amarilli <a3nm@a3nm.net>

To: Chris Lamb <lamby@debian.org>

Cc: 830726@bugs.debian.org

Subject: Re: Bug#830726: closed by Chris Lamb <lamby@debian.org> (Bug#830726: fixed in xtrlock 2.12)

Date: Wed, 16 Oct 2019 08:24:37 +0200

[Message part 1 (text/plain, inline)]

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

Best,

-- 
Antoine Amarilli


On Wed, Oct 16, 2019 at 12:57:16AM -0000, Chris Lamb wrote:
> 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,
> 
> -- 
>       ,''`.
>      : :'  :     Chris Lamb
>      `. `'`      lamby@debian.org 🍥 chris-lamb.co.uk
>        `-

[signature.asc (application/pgp-signature, inline)]

Message #160 received at 830726-close@bugs.debian.org (full text, mbox, reply):

From: Debian FTP Masters <ftpmaster@ftp-master.debian.org>

To: 830726-close@bugs.debian.org

Subject: Bug#830726: fixed in xtrlock 2.8+deb10u1

Date: Sat, 14 Mar 2020 19:17:10 +0000

Source: xtrlock
Source-Version: 2.8+deb10u1
Done: Chris Lamb <lamby@debian.org>

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
have further comments please address them to 830726@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Chris Lamb <lamby@debian.org> (supplier of updated xtrlock package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Thu, 16 Jan 2020 16:00:52 +0000
Source: xtrlock
Architecture: source
Version: 2.8+deb10u1
Distribution: buster
Urgency: high
Maintainer: Matthew Vernon <matthew@debian.org>
Changed-By: Chris Lamb <lamby@debian.org>
Closes: 830726
Changes:
 xtrlock (2.8+deb10u1) buster; urgency=high
 .
   * CVE-2016-10894: Attempt to grab multitouch devices which are not
     intercepted via XGrabPointer.
 .
     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.
 .
     This fix does not the situation where Eve plugs in a multitouch device
     *after* the screen has been locked. For more information on this angle,
     please see <https://bugs.debian.org/830726#115>. (Closes: #830726)
Checksums-Sha1:
 f950ec30c91399896229718af98d97887e404aca 1461 xtrlock_2.8+deb10u1.dsc
 a83b0156c4d792af244aea0ae9ff89a735c5f247 21907 xtrlock_2.8+deb10u1.tar.gz
 5a0fed0546a8189a3f9f2c1cb382f0cc3de7a19a 5076 xtrlock_2.8+deb10u1_amd64.buildinfo
Checksums-Sha256:
 afcd1196e84993cf13bd82c06c946010f6bb80169a69922bb121b2720cfc8aff 1461 xtrlock_2.8+deb10u1.dsc
 0aa7025c298d9590ac39270c159d460d327fcab0c71045f257905221e8b2f535 21907 xtrlock_2.8+deb10u1.tar.gz
 b471cd73c2e9bbd2bc868fdc2a52bf8782ab3b98d679012c550cb320de2878d2 5076 xtrlock_2.8+deb10u1_amd64.buildinfo
Files:
 3274cf204947ca02b47dc102d4455154 1461 x11 optional xtrlock_2.8+deb10u1.dsc
 4516ca210599526c63d382367d53a93b 21907 x11 optional xtrlock_2.8+deb10u1.tar.gz
 b6f9d6e2d975cf1b15fa4759e2e57890 5076 x11 optional xtrlock_2.8+deb10u1_amd64.buildinfo

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEwv5L0nHBObhsUz5GHpU+J9QxHlgFAl5hVAsACgkQHpU+J9Qx
HlgI1hAAg5LlkKCvwuWw327rtSvhSzW82odVi2OfK90PvzP2v1D6/yGTYGz0VXaf
0X1u83UcP31MX4sib8FnoxjFkI4jtSzEouyDF7MXxsYWCFLlqp2VbcLbjYtDEI12
lz+MpYah5Itle7dI+rHjKAvJlttC2B5DtPrf8PlLP31ePv5UabOWU+m/uJX/ua9j
mw3jbX+ZPdG9UwCUW9sIWP4+SqdWnbBCWHxbDutrgjrZlNSVSY8dDkPTlvYfp7wq
TxbtTnAWGtadI8fdbmeeShpKux7Nsh6ucQHgw+/JT8msrDiItUA2L/Rr3dVK3H1y
W6t9moyxhMgGqdatrkeg66/hXBvFDbJoPEwj9swi9Tnb1IHtTzYjBRZK/Hxs+Gnn
HjSOePfZjSjSPR7hl/LkP/53Kq0yg1VlcN5DejgrfYGODZnaYVamcyrJxo2YPLn0
STQTYKCiL6hXJWQolbkuFoOWk/btqJDouyohluIWCMpSe4jW3/Y4Mq6oL4VE+GhB
SJySq4+0+pbc5u3wQbBh4fXr2SVUshvtq1jk97yuHGorsl6SPCq6Vp3/EGF8RERM
7gjarms7Ko8jIbms7xu8lg8S4RSzdzPBI8fZazQ6GDe6+bT1vnY7WB5Doau4SMT+
yw5X+txBETQjtHOkbJLRSIHA4spSawXOJzQa8+hsTvfaIS9eg/s=
=mcjU
-----END PGP SIGNATURE-----

Message #165 received at 830726-close@bugs.debian.org (full text, mbox, reply):

From: Debian FTP Masters <ftpmaster@ftp-master.debian.org>

To: 830726-close@bugs.debian.org

Subject: Bug#830726: fixed in xtrlock 2.8+deb9u1

Date: Sun, 22 Mar 2020 20:42:49 +0000

Source: xtrlock
Source-Version: 2.8+deb9u1
Done: Chris Lamb <lamby@debian.org>

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
have further comments please address them to 830726@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Chris Lamb <lamby@debian.org> (supplier of updated xtrlock package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Thu, 16 Jan 2020 16:00:52 +0000
Source: xtrlock
Binary: xtrlock
Architecture: source
Version: 2.8+deb9u1
Distribution: stretch
Urgency: high
Maintainer: Matthew Vernon <matthew@debian.org>
Changed-By: Chris Lamb <lamby@debian.org>
Description:
 xtrlock    - Minimal X display lock program
Closes: 830726
Changes:
 xtrlock (2.8+deb9u1) stretch; urgency=high
 .
   * CVE-2016-10894: Attempt to grab multitouch devices which are not
     intercepted via XGrabPointer.
 .
     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.
 .
     This fix does not the situation where Eve plugs in a multitouch device
     *after* the screen has been locked. For more information on this angle,
     please see <https://bugs.debian.org/830726#115>. (Closes: #830726)
Checksums-Sha1:
 3868359c01d305263ab4a2d75a3b782a18947bcc 1457 xtrlock_2.8+deb9u1.dsc
 e3a12ff00c5e7b01ab5d093eafa1e26defb24f0b 21823 xtrlock_2.8+deb9u1.tar.gz
 28f7890c85279f310c5256e3174e4760aba36072 5503 xtrlock_2.8+deb9u1_amd64.buildinfo
Checksums-Sha256:
 0c165522c0f09e3ca44ccd26e1bc24ae6496aee76c4ae1216805b8127a4e3387 1457 xtrlock_2.8+deb9u1.dsc
 33c26b5c1e345c6840e54f636316fa43de230872dce235f48cc81e1ceaae5bbe 21823 xtrlock_2.8+deb9u1.tar.gz
 d874d380feb66b97c89e42553a149a2d17e6e58643f05094af8d2b4b19e9ec56 5503 xtrlock_2.8+deb9u1_amd64.buildinfo
Files:
 d4f93d24d9d9194396c39cfa3b499d67 1457 x11 optional xtrlock_2.8+deb9u1.dsc
 8949706713aef3b3e1c23ed194ff2510 21823 x11 optional xtrlock_2.8+deb9u1.tar.gz
 0bd7a99543e9251a7a824d24305b032b 5503 x11 optional xtrlock_2.8+deb9u1_amd64.buildinfo

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEwv5L0nHBObhsUz5GHpU+J9QxHlgFAl5hU9cACgkQHpU+J9Qx
HlhopA//UQXxNs6P7ZBECuA/RB9Y+zv+onobiNl1a65gMFA1YR9BNp8EbuXnIXGe
DtaPV3GcFi0qKotx2KJUOYvixiQAMpB7qTwXyOZAcPbd9QyLzHH1OkXRQZPWOckw
caKeew69XbxbUyc9nJN49LFgtmp2sVL7v3IZV2xe6az4O5f5nJDGtKnWEo3K2Xzx
Jpgbi5/K+xwIutOJjgUDgKM0PMbBUbgqLvW4m1JVuwaQeeXhrFzqYfp3iOAPv7iM
stIZiPSBpZyImmEgPnRUMAQFRHUZFTA93zivnevve3DaQcZ6Twz+XyaVWBF2tGiL
yeJNnRuLWJaMKit75WveCOUxZcmkKr0m8WaUBg/ysSm7VZ54/pbH2A2Kp9/TO+KX
pd0Ud+KprgJ1R3BDYL6B1OMf9LC/1Jwj5E9CGZSclC0lhO8xl6niR+Mh4q9yJAaF
1oEveB5FJdd5fuQ3M6eCE8XXopjl6zgaDgzERHeDIgcUy63sznb2Ew4BY56hHF3q
eVzubh9U88qgav6NQl8A8zMX5GNP55TZqlQ8WoQTyb6vq+T/VvPy1QBDdPyhZGSX
u+mCc4DDwcyL0jbynvnHNwpeN+JUGXaNXJvCzA9IlISV+aZCdoXs7esWyo7lbQzq
ilpiEtj+T4lJYxPDx9EjpgJ9xYI09NgVcnnJkINm8nJgYabQ5qU=
=kBvR
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.