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
Description: PGP signature
