![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59Update: While this isn't strictly fixed (Mir will still perform a VT switch without waiting to ensure that XMir has released the input devices), the time window for console input events to end up in XMir is now small enough that it's probably not a security problem any more.
It'd be easy to assume that in a Mir-based world, the Mir server receives input events and hands them over to Mir clients. In fact, as I described here, XMir uses standard Xorg input drivers and so receives all input events directly. This led to issues like the duplicate mouse pointer seen in earlier versions of XMir - as well as the pointer being drawn by XMir, Mir was drawing its own pointer.
But there's also some more subtle issues. Mir recently gained a fairly simple implementation of VT switching, simply listening for input events where a function key is hit while the ctrl and alt modifiers are set[1]. It then performs the appropriate ioctl on /dev/console and the kernel switches the VT. The problem here is that Mir doesn't tell XMir that this has happened, and so XMir still has all of its input devices open and still pays attention to any input events.
This is pretty easy to demonstrate. Open a terminal or text editor under Xmir and make sure it has focus. Hit ctrl+alt+f1 and log in. Hit ctlr+alt+f7 again. Your username and password will be sitting in the window.
This is Launchpad bug 1192843, filed on the 20th of June. A month and a half later, Mir was added to the main Ubuntu repositories. Towards the bottom, there's a note saying "XMir always listening to keyboard, passwords may appear in other X sessions". This is pretty misleading, since "other X sessions" implies that it's only going to happen if you run multiple X sessions. Regardless, it's a known bug that can potentially leak user passwords.
So it's kind of odd that that's the only mention of it, hidden in a disused toilet behind a "Doesn't work on VESA" sign. If you follow the link to installation instructions you get this page which doesn't mention the problem at all. Now, to be fair, it doesn't mention any of the other problems with Mir either, but the other problems merely result in things not working rather than your password ending up in IRC.
This being developmental software isn't an excuse. There's been plenty of Canonical-led publicity about Mir and people are inevitably going to test it out. The lack of clear and explicit warnings is utterly inexcusable, and these packages shouldn't have landed in the archive until the issue was fixed. This is brutally irresponsible behaviour on the part of Canonical.
So, if you ever switch to a text VT, either make sure you're not running XMir at the moment or make sure that you never leave any kind of network client focused when you switch away from X. And you might want to check IRC and IM logs to make sure you haven't made a mistake already.
[1] One lesser-known feature of X is that the VT switching events are actually configured in the keymap. ctrl+alt+f1 defaults to switching to VT1, but you can remap any key combination to any VT switch event. Except, of course, this is broken in XMir because Mir catches the keystroke and handles it anyway.
It'd be easy to assume that in a Mir-based world, the Mir server receives input events and hands them over to Mir clients. In fact, as I described here, XMir uses standard Xorg input drivers and so receives all input events directly. This led to issues like the duplicate mouse pointer seen in earlier versions of XMir - as well as the pointer being drawn by XMir, Mir was drawing its own pointer.
But there's also some more subtle issues. Mir recently gained a fairly simple implementation of VT switching, simply listening for input events where a function key is hit while the ctrl and alt modifiers are set[1]. It then performs the appropriate ioctl on /dev/console and the kernel switches the VT. The problem here is that Mir doesn't tell XMir that this has happened, and so XMir still has all of its input devices open and still pays attention to any input events.
This is pretty easy to demonstrate. Open a terminal or text editor under Xmir and make sure it has focus. Hit ctrl+alt+f1 and log in. Hit ctlr+alt+f7 again. Your username and password will be sitting in the window.
This is Launchpad bug 1192843, filed on the 20th of June. A month and a half later, Mir was added to the main Ubuntu repositories. Towards the bottom, there's a note saying "XMir always listening to keyboard, passwords may appear in other X sessions". This is pretty misleading, since "other X sessions" implies that it's only going to happen if you run multiple X sessions. Regardless, it's a known bug that can potentially leak user passwords.
So it's kind of odd that that's the only mention of it, hidden in a disused toilet behind a "Doesn't work on VESA" sign. If you follow the link to installation instructions you get this page which doesn't mention the problem at all. Now, to be fair, it doesn't mention any of the other problems with Mir either, but the other problems merely result in things not working rather than your password ending up in IRC.
This being developmental software isn't an excuse. There's been plenty of Canonical-led publicity about Mir and people are inevitably going to test it out. The lack of clear and explicit warnings is utterly inexcusable, and these packages shouldn't have landed in the archive until the issue was fixed. This is brutally irresponsible behaviour on the part of Canonical.
So, if you ever switch to a text VT, either make sure you're not running XMir at the moment or make sure that you never leave any kind of network client focused when you switch away from X. And you might want to check IRC and IM logs to make sure you haven't made a mistake already.
[1] One lesser-known feature of X is that the VT switching events are actually configured in the keymap. ctrl+alt+f1 defaults to switching to VT1, but you can remap any key combination to any VT switch event. Except, of course, this is broken in XMir because Mir catches the keystroke and handles it anyway.
Re: only users running Xmir *and* using VTs *and* chat apps are impacted
Date: 2013-09-18 08:53 pm (UTC)Note that this bug, discovered in June, has never been one of the 'target' aka milestone bugs, for ubuntu 13.07 thru 13.09 -- see https://launchpad.net/ubuntu/+milestone/ubuntu-13.10 Furthermore, although security is mentioned from time to time in the target-lists, it does not seem to be the priority, for instance AppArmor here... https://blueprints.launchpad.net/ubuntu/+spec/security-s-appisolation-display-manager ... which is now deferred (until after the 13.10 release presumably)
Note that, although in terms of the *overall* concerns related to the 13.10 release, security seems to take a back seat (at least from my limited glance at the buglist and milestones), the mir sub-project itself seems to be taking it somewhat seriously. As of today, the first bug on the mir buglist is 'xmir rcvs input from vt' -- https://bugs.launchpad.net/mir -- and it was targeted for the mir v0.10 release here -- https://launchpad.net/mir/+milestone/0.0.10
The security warning status of the Ubuntu documentation is still hit and miss. Here is a good page, which tells you right at the top about the potential security risk, as well as driver support and other necessities: https://wiki.ubuntu.com/Mir/Installing By contrast, if you instead were on this page, http://unity.ubuntu.com/mir/ , you get no warning at all. "If you just want to try out mir, or write client applications, then the easiest way is to use the pre-built packages" Maybe you get a warning after you actually download and install said pre-built packages? Sloppy, though, either way.
I understand that Canonical is trying to get Mir alpha-tested by as many endusers as possible before it is released as the default for 13.10 (which itself is pretty much a beta-test of mir for the LTS 14.04 release that will happen early next year). But I'd be happier if they did not cut documentation-corners with security-related bugs. Not acceptable that the desire to ship early and often is sometimes trumping the desire to keep endusers from revealing their passwords to the internet. Security precautions should apply to alpha-testing folks, not just LTS users next year.