Headline
CVE-2016-10894: #830726 - xtrlock: CVE-2016-10894: xtrlock does not block multitouch events
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).
Reported by: Antoine Amarilli [email protected]
Date: Sun, 10 Jul 2016 20:21:02 UTC
Severity: grave
Tags: patch, security, upstream
Found in version xtrlock/2.8
Fixed in versions xtrlock/2.12, xtrlock/2.8+deb10u1, xtrlock/2.8+deb9u1
Done: Chris Lamb [email protected]
Bug is archived. No further changes may be made.
Toggle useless messages
Report forwarded to [email protected], [email protected], Matthew Vernon [email protected]:
Bug#830726; Package xtrlock. (Sun, 10 Jul 2016 20:21:06 GMT) (full text, mbox, link).
Acknowledgement sent to Antoine Amarilli [email protected]:
New Bug report received and forwarded. Copy sent to [email protected], Matthew Vernon [email protected]. (Sun, 10 Jul 2016 20:21:07 GMT) (full text, mbox, link).
Message #5 received at [email protected] (full text, mbox, reply):
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):
- Open chromium (my example of a program that processes multitouch events) and put it in fullscreen mode.
- 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).
- Run xtrlock to lock the session.
- 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
Information forwarded to [email protected], Matthew Vernon [email protected]:
Bug#830726; Package xtrlock. (Sun, 21 Jul 2019 18:39:09 GMT) (full text, mbox, link).
Acknowledgement sent to “Chris Lamb” [email protected]:
Extra info received and forwarded to list. Copy sent to Matthew Vernon [email protected]. (Sun, 21 Jul 2019 18:39:09 GMT) (full text, mbox, link).
Message #10 received at [email protected] (full text, mbox, reply):
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 `. `’` [email protected] / chris-lamb.co.uk `-
Information forwarded to [email protected], Matthew Vernon [email protected]:
Bug#830726; Package xtrlock. (Fri, 09 Aug 2019 23:51:03 GMT) (full text, mbox, link).
Acknowledgement sent to Antoine Amarilli [email protected]:
Extra info received and forwarded to list. Copy sent to Matthew Vernon [email protected]. (Fri, 09 Aug 2019 23:51:03 GMT) (full text, mbox, link).
Message #15 received at [email protected] (full text, mbox, reply):
[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)]
Information forwarded to [email protected], Matthew Vernon [email protected]:
Bug#830726; Package xtrlock. (Sun, 11 Aug 2019 13:03:03 GMT) (full text, mbox, link).
Acknowledgement sent to “Chris Lamb” [email protected]:
Extra info received and forwarded to list. Copy sent to Matthew Vernon [email protected]. (Sun, 11 Aug 2019 13:03:03 GMT) (full text, mbox, link).
Message #20 received at [email protected] (full text, mbox, reply):
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 `. `’` [email protected] 🍥 chris-lamb.co.uk `-
Severity set to ‘important’ from ‘normal’ Request was from “Chris Lamb” [email protected] to [email protected]. (Sun, 11 Aug 2019 13:09:07 GMT) (full text, mbox, link).
Information forwarded to [email protected], Matthew Vernon [email protected]:
Bug#830726; Package xtrlock. (Fri, 16 Aug 2019 04:18:03 GMT) (full text, mbox, link).
Acknowledgement sent to Salvatore Bonaccorso [email protected]:
Extra info received and forwarded to list. Copy sent to Matthew Vernon [email protected]. (Fri, 16 Aug 2019 04:18:03 GMT) (full text, mbox, link).
Message #27 received at [email protected] (full text, mbox, reply):
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
Added tag(s) security. Request was from Salvatore Bonaccorso [email protected] to [email protected]. (Fri, 16 Aug 2019 04:18:03 GMT) (full text, mbox, link).
Changed Bug title to ‘xtrlock: CVE-2016-10894: xtrlock does not block multitouch events’ from 'xtrlock does not block multitouch events’. Request was from Salvatore Bonaccorso [email protected] to [email protected]. (Fri, 16 Aug 2019 04:18:04 GMT) (full text, mbox, link).
Information forwarded to [email protected], Matthew Vernon [email protected]:
Bug#830726; Package xtrlock. (Fri, 16 Aug 2019 15:24:04 GMT) (full text, mbox, link).
Acknowledgement sent to “Chris Lamb” [email protected]:
Extra info received and forwarded to list. Copy sent to Matthew Vernon [email protected]. (Fri, 16 Aug 2019 15:24:04 GMT) (full text, mbox, link).
Message #36 received at [email protected] (full text, mbox, reply):
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 `. `’` [email protected] / chris-lamb.co.uk `-
Severity set to ‘grave’ from ‘important’ Request was from “Chris Lamb” [email protected] to [email protected]. (Fri, 16 Aug 2019 15:24:07 GMT) (full text, mbox, link).
Information forwarded to [email protected], Matthew Vernon [email protected]:
Bug#830726; Package xtrlock. (Fri, 16 Aug 2019 15:30:03 GMT) (full text, mbox, link).
Acknowledgement sent to “Chris Lamb” [email protected]:
Extra info received and forwarded to list. Copy sent to Matthew Vernon [email protected]. (Fri, 16 Aug 2019 15:30:03 GMT) (full text, mbox, link).
Message #43 received at [email protected] (full text, mbox, reply):
[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 `. `’` [email protected] / chris-lamb.co.uk `-
[0001-Attempt-to-grab-multitouch-devices-which-are-not-int.patch (text/x-patch, attachment)]
Added tag(s) patch. Request was from “Chris Lamb” [email protected] to [email protected]. (Fri, 16 Aug 2019 15:30:05 GMT) (full text, mbox, link).
Information forwarded to [email protected], Matthew Vernon [email protected]:
Bug#830726; Package xtrlock. (Sat, 17 Aug 2019 00:51:03 GMT) (full text, mbox, link).
Acknowledgement sent to “Chris Lamb” [email protected]:
Extra info received and forwarded to list. Copy sent to Matthew Vernon [email protected]. (Sat, 17 Aug 2019 00:51:03 GMT) (full text, mbox, link).
Message #50 received at [email protected] (full text, mbox, reply):
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 `. `’` [email protected] 🍥 chris-lamb.co.uk `-
Information forwarded to [email protected], Matthew Vernon [email protected]:
Bug#830726; Package xtrlock. (Sun, 18 Aug 2019 10:12:06 GMT) (full text, mbox, link).
Acknowledgement sent to Antoine Amarilli [email protected]:
Extra info received and forwarded to list. Copy sent to Matthew Vernon [email protected]. (Sun, 18 Aug 2019 10:12:06 GMT) (full text, mbox, link).
Message #55 received at [email protected] (full text, mbox, reply):
[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 `. `’` [email protected] 🍥 chris-lamb.co.uk `-
[signature.asc (application/pgp-signature, inline)]
Information forwarded to [email protected], Matthew Vernon [email protected]:
Bug#830726; Package xtrlock. (Tue, 20 Aug 2019 21:12:03 GMT) (full text, mbox, link).
Acknowledgement sent to “Chris Lamb” [email protected]:
Extra info received and forwarded to list. Copy sent to Matthew Vernon [email protected]. (Tue, 20 Aug 2019 21:12:03 GMT) (full text, mbox, link).
Message #60 received at [email protected] (full text, mbox, reply):
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 `. `’` [email protected] 🍥 chris-lamb.co.uk `-
Information forwarded to [email protected], Matthew Vernon [email protected]:
Bug#830726; Package xtrlock. (Wed, 21 Aug 2019 22:57:05 GMT) (full text, mbox, link).
Acknowledgement sent to “Chris Lamb” [email protected]:
Extra info received and forwarded to list. Copy sent to Matthew Vernon [email protected]. (Wed, 21 Aug 2019 22:57:05 GMT) (full text, mbox, link).
Message #65 received at [email protected] (full text, mbox, reply):
[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 `. `’` [email protected] 🍥 chris-lamb.co.uk `-
[0001-Attempt-to-grab-multitouch-devices-which-are-not-int.patch (text/x-patch, attachment)]
Information forwarded to [email protected], Matthew Vernon [email protected]:
Bug#830726; Package xtrlock. (Thu, 22 Aug 2019 17:54:02 GMT) (full text, mbox, link).
Acknowledgement sent to Antoine Amarilli [email protected]:
Extra info received and forwarded to list. Copy sent to Matthew Vernon [email protected]. (Thu, 22 Aug 2019 17:54:03 GMT) (full text, mbox, link).
Message #70 received at [email protected] (full text, mbox, reply):
[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)]
Information forwarded to [email protected], Matthew Vernon [email protected]:
Bug#830726; Package xtrlock. (Thu, 22 Aug 2019 18:15:03 GMT) (full text, mbox, link).
Acknowledgement sent to “Chris Lamb” [email protected]:
Extra info received and forwarded to list. Copy sent to Matthew Vernon [email protected]. (Thu, 22 Aug 2019 18:15:03 GMT) (full text, mbox, link).
Message #75 received at [email protected] (full text, mbox, reply):
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 `. `’` [email protected] 🍥 chris-lamb.co.uk `-
Information forwarded to [email protected], Matthew Vernon [email protected]:
Bug#830726; Package xtrlock. (Thu, 22 Aug 2019 23:03:03 GMT) (full text, mbox, link).
Acknowledgement sent to “Chris Lamb” [email protected]:
Extra info received and forwarded to list. Copy sent to Matthew Vernon [email protected]. (Thu, 22 Aug 2019 23:03:03 GMT) (full text, mbox, link).
Message #80 received at [email protected] (full text, mbox, reply):
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 `. `’` [email protected] 🍥 chris-lamb.co.uk `-
Information forwarded to [email protected]:
Bug#830726; Package xtrlock. (Thu, 22 Aug 2019 23:24:03 GMT) (full text, mbox, link).
Acknowledgement sent to Matthew Vernon [email protected]:
Extra info received and forwarded to list. (Thu, 22 Aug 2019 23:24:03 GMT) (full text, mbox, link).
Message #85 received at [email protected] (full text, mbox, reply):
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
Information forwarded to [email protected], Matthew Vernon [email protected]:
Bug#830726; Package xtrlock. (Fri, 23 Aug 2019 20:21:10 GMT) (full text, mbox, link).
Acknowledgement sent to Antoine Amarilli [email protected]:
Extra info received and forwarded to list. Copy sent to Matthew Vernon [email protected]. (Fri, 23 Aug 2019 20:21:10 GMT) (full text, mbox, link).
Message #90 received at [email protected] (full text, mbox, reply):
[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)]
Information forwarded to [email protected], Matthew Vernon [email protected]:
Bug#830726; Package xtrlock. (Sun, 08 Sep 2019 08:42:03 GMT) (full text, mbox, link).
Acknowledgement sent to “Chris Lamb” [email protected]:
Extra info received and forwarded to list. Copy sent to Matthew Vernon [email protected]. (Sun, 08 Sep 2019 08:42:03 GMT) (full text, mbox, link).
Message #95 received at [email protected] (full text, mbox, reply):
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 `. `’` [email protected] 🍥 chris-lamb.co.uk `-
Information forwarded to [email protected], Matthew Vernon [email protected]:
Bug#830726; Package xtrlock. (Sun, 08 Sep 2019 10:18:03 GMT) (full text, mbox, link).
Acknowledgement sent to Antoine Amarilli [email protected]:
Extra info received and forwarded to list. Copy sent to Matthew Vernon [email protected]. (Sun, 08 Sep 2019 10:18:03 GMT) (full text, mbox, link).
Message #100 received at [email protected] (full text, mbox, reply):
[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)]
Information forwarded to [email protected], Matthew Vernon [email protected]:
Bug#830726; Package xtrlock. (Sun, 08 Sep 2019 15:21:11 GMT) (full text, mbox, link).
Acknowledgement sent to “Chris Lamb” [email protected]:
Extra info received and forwarded to list. Copy sent to Matthew Vernon [email protected]. (Sun, 08 Sep 2019 15:21:11 GMT) (full text, mbox, link).
Message #105 received at [email protected] (full text, mbox, reply):
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 `. `’` [email protected] 🍥 chris-lamb.co.uk `-
Information forwarded to [email protected], Matthew Vernon [email protected]:
Bug#830726; Package xtrlock. (Tue, 10 Sep 2019 11:51:06 GMT) (full text, mbox, link).
Acknowledgement sent to “Chris Lamb” [email protected]:
Extra info received and forwarded to list. Copy sent to Matthew Vernon [email protected]. (Tue, 10 Sep 2019 11:51:06 GMT) (full text, mbox, link).
Message #110 received at [email protected] (full text, mbox, reply):
[adding [email protected] to CC, dropping [email protected]; 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 `. `’` [email protected] 🍥 chris-lamb.co.uk `-
Information forwarded to [email protected], Matthew Vernon [email protected]:
Bug#830726; Package xtrlock. (Sun, 22 Sep 2019 15:06:08 GMT) (full text, mbox, link).
Acknowledgement sent to “Chris Lamb” [email protected]:
Extra info received and forwarded to list. Copy sent to Matthew Vernon [email protected]. (Sun, 22 Sep 2019 15:06:08 GMT) (full text, mbox, link).
Message #115 received at [email protected] (full text, mbox, reply):
[adding [email protected] to CC, dropping [email protected]; 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 `. `’` [email protected] 🍥 chris-lamb.co.uk `-
Reply sent to Chris Lamb [email protected]:
You have taken responsibility. (Fri, 11 Oct 2019 19:57:03 GMT) (full text, mbox, link).
Notification sent to Antoine Amarilli [email protected]:
Bug acknowledged by developer. (Fri, 11 Oct 2019 19:57:03 GMT) (full text, mbox, link).
Message #120 received at [email protected] (full text, mbox, reply):
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 [email protected], and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software pp. Chris Lamb [email protected] (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 [email protected])
-----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 [email protected] Changed-By: Chris Lamb [email protected] 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-----
Information forwarded to [email protected], Matthew Vernon [email protected]:
Bug#830726; Package xtrlock. (Sat, 12 Oct 2019 13:06:03 GMT) (full text, mbox, link).
Acknowledgement sent to Antoine Amarilli [email protected]:
Extra info received and forwarded to list. Copy sent to Matthew Vernon [email protected]. (Sat, 12 Oct 2019 13:06:03 GMT) (full text, mbox, link).
Message #125 received at [email protected] (full text, mbox, reply):
[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 [email protected].
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 [email protected] by replying to this email.
– 830726: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830726 Debian Bug Tracking System Contact [email protected] with problems
Date: Fri, 11 Oct 2019 19:52:58 +0000 From: Chris Lamb [email protected] To: [email protected] Subject: Bug#830726: fixed in xtrlock 2.12 Message-Id: [email protected]
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 [email protected], and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software pp. Chris Lamb [email protected] (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 [email protected])
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 [email protected] Changed-By: Chris Lamb [email protected] 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 [email protected] To: Debian Bug Tracking System [email protected] Subject: xtrlock does not block multitouch events Message-ID: [email protected] 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):
- Open chromium (my example of a program that processes multitouch events) and put it in fullscreen mode.
- 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).
- Run xtrlock to lock the session.
- 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)]
Information forwarded to [email protected], Matthew Vernon [email protected]:
Bug#830726; Package xtrlock. (Sat, 12 Oct 2019 19:15:03 GMT) (full text, mbox, link).
Acknowledgement sent to “Chris Lamb” [email protected]:
Extra info received and forwarded to list. Copy sent to Matthew Vernon [email protected]. (Sat, 12 Oct 2019 19:15:03 GMT) (full text, mbox, link).
Message #130 received at [email protected] (full text, mbox, reply):
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 `. `’` [email protected] 🍥 chris-lamb.co.uk `-
Information forwarded to [email protected], Matthew Vernon [email protected]:
Bug#830726; Package xtrlock. (Mon, 14 Oct 2019 09:33:03 GMT) (full text, mbox, link).
Acknowledgement sent to Antoine Amarilli [email protected]:
Extra info received and forwarded to list. Copy sent to Matthew Vernon [email protected]. (Mon, 14 Oct 2019 09:33:04 GMT) (full text, mbox, link).
Message #135 received at [email protected] (full text, mbox, reply):
[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)]
Information forwarded to [email protected], Matthew Vernon [email protected]:
Bug#830726; Package xtrlock. (Mon, 14 Oct 2019 19:15:03 GMT) (full text, mbox, link).
Acknowledgement sent to “Chris Lamb” [email protected]:
Extra info received and forwarded to list. Copy sent to Matthew Vernon [email protected]. (Mon, 14 Oct 2019 19:15:03 GMT) (full text, mbox, link).
Message #140 received at [email protected] (full text, mbox, reply):
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 `. `’` [email protected] 🍥 chris-lamb.co.uk `-
Information forwarded to [email protected], Matthew Vernon [email protected]:
Bug#830726; Package xtrlock. (Tue, 15 Oct 2019 06:15:03 GMT) (full text, mbox, link).
Acknowledgement sent to Antoine Amarilli [email protected]:
Extra info received and forwarded to list. Copy sent to Matthew Vernon [email protected]. (Tue, 15 Oct 2019 06:15:03 GMT) (full text, mbox, link).
Message #145 received at [email protected] (full text, mbox, reply):
[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 `. `’` [email protected] 🍥 chris-lamb.co.uk `-
[signature.asc (application/pgp-signature, inline)]
Information forwarded to [email protected], Matthew Vernon [email protected]:
Bug#830726; Package xtrlock. (Wed, 16 Oct 2019 01:00:03 GMT) (full text, mbox, link).
Acknowledgement sent to “Chris Lamb” [email protected]:
Extra info received and forwarded to list. Copy sent to Matthew Vernon [email protected]. (Wed, 16 Oct 2019 01:00:03 GMT) (full text, mbox, link).
Message #150 received at [email protected] (full text, mbox, reply):
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 `. `’` [email protected] 🍥 chris-lamb.co.uk `-
Information forwarded to [email protected], Matthew Vernon [email protected]:
Bug#830726; Package xtrlock. (Wed, 16 Oct 2019 06:27:03 GMT) (full text, mbox, link).
Acknowledgement sent to Antoine Amarilli [email protected]:
Extra info received and forwarded to list. Copy sent to Matthew Vernon [email protected]. (Wed, 16 Oct 2019 06:27:03 GMT) (full text, mbox, link).
Message #155 received at [email protected] (full text, mbox, reply):
[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 `. `’` [email protected] 🍥 chris-lamb.co.uk `-
[signature.asc (application/pgp-signature, inline)]
Reply sent to Chris Lamb [email protected]:
You have taken responsibility. (Sat, 14 Mar 2020 19:21:08 GMT) (full text, mbox, link).
Notification sent to Antoine Amarilli [email protected]:
Bug acknowledged by developer. (Sat, 14 Mar 2020 19:21:08 GMT) (full text, mbox, link).
Message #160 received at [email protected] (full text, mbox, reply):
Source: xtrlock Source-Version: 2.8+deb10u1 Done: Chris Lamb [email protected]
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 [email protected], and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software pp. Chris Lamb [email protected] (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 [email protected])
-----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 [email protected] Changed-By: Chris Lamb [email protected] 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-----
Reply sent to Chris Lamb [email protected]:
You have taken responsibility. (Sun, 22 Mar 2020 20:45:03 GMT) (full text, mbox, link).
Notification sent to Antoine Amarilli [email protected]:
Bug acknowledged by developer. (Sun, 22 Mar 2020 20:45:03 GMT) (full text, mbox, link).
Message #165 received at [email protected] (full text, mbox, reply):
Source: xtrlock Source-Version: 2.8+deb9u1 Done: Chris Lamb [email protected]
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 [email protected], and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software pp. Chris Lamb [email protected] (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 [email protected])
-----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 [email protected] Changed-By: Chris Lamb [email protected] 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-----
Bug archived. Request was from Debbugs Internal Request [email protected] to [email protected]. (Sun, 10 May 2020 07:26:20 GMT) (full text, mbox, link).
Send a report that this bug log contains spam.
Debian bug tracking system administrator <[email protected]>. Last modified: Fri Mar 31 16:04:17 2023; Machine Name: bembo
Debian Bug tracking system
Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.
Copyright © 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson, 2005-2017 Don Armstrong, and many other contributors.