![[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.
On names, again.
Date: 2013-08-22 09:26 am (UTC)The *buntu people assured me that “Mir” would just be a codename with no user visibility. I suggest you write “The *buntu display server codenamed Mir” or something like that.
Otherwise, “Mir*” stuff in general comes from The MirOS Project („MirBSD“).
Re: On names, again.
Date: 2013-08-22 10:29 am (UTC)If you have an issue with the name, take it up with Canonical. Matthew is quite correct in calling it that.
Re: On names, again.
Date: 2013-08-22 11:44 am (UTC)Public visibility of that name will be limited to some libraries and headers. But only really seen by developers.
https://bugs.launchpad.net/mir/+bug/1145358
Re: On names, again.
Date: 2013-08-22 01:02 pm (UTC)Might be time to chase them again, see if they'll rename?
Re: On names, again.
Date: 2013-08-22 11:43 pm (UTC)(Michael Hall here, why doesn't dreamhost accept my Launchpad OpenID? I tried to do the right thing and register.)
Re: On names, again.
Date: 2013-08-23 04:09 am (UTC)Re: On names, again.
Date: 2013-09-26 12:04 am (UTC)Re: On names, again.
Date: 2013-08-22 01:24 pm (UTC)Mir is de facto the name of Ubuntu diplay server
Re: On names, again.
Date: 2013-08-22 04:17 pm (UTC)Re: On names, again.
Date: 2013-08-23 12:58 am (UTC)I think this is nice change to have codename forged from "foreign" word and to make "native" speakers see there is a lot more in this world beyond english language. Bottom line in some parts of the world when you say mir i assure you this is not associated directly with space stations.
Re: On names, again.
Date: 2013-08-23 08:01 pm (UTC)Re: On names, again.
Date: 2013-08-23 09:44 pm (UTC)And somebody mentioned copyright i must say i doubt it would be possible to copyright the name Mir for any specific product.
hunter2
Date: 2013-08-22 09:53 am (UTC)Re: hunter2
Date: 2013-08-22 08:25 pm (UTC)Don't tell them
Date: 2013-08-22 01:58 pm (UTC)likelyhood? high
Date: 2013-08-22 02:10 pm (UTC)Re: likelyhood? high
Date: 2013-08-24 08:21 pm (UTC)Mir
Date: 2013-08-22 07:48 pm (UTC)Well...
Date: 2013-08-22 09:34 pm (UTC)I am not sure this issue is "brutally irresponsible" or more of an oversight. Agreed that this is a significant security issue, but I would consider this more "brually irresponsible" if this bug was present when XMir is switched on by default in 13.10. In the meantime, it is a bug...an important bug...but a bug.
Fortunately the bug is currently getting fixed.
Re: Well...
Date: 2013-08-22 09:53 pm (UTC)Re: Well...
Date: 2013-08-23 07:04 pm (UTC)If the Mir team were encouraging testing are as intimately familiar with the risk as you highlight here, then I agree it would be "brutally irresponsible". I am just not entirely sure they knew the risk.
Re: Well...
Date: 2013-08-23 08:00 pm (UTC)Re: Well...
Date: 2013-08-25 02:19 pm (UTC)You are missing my point. My point is that there is a possibility that the wider team simply didn't understand the significance of the bug in terms of a security issue.
Re: Well...
Date: 2013-08-25 02:36 pm (UTC)sessions" is mentioned in the original mail, right down at the bottom. The Mir team appear to have been fully aware that it was a security sensitive problem.
Re: hunter2
Date: 2013-08-25 07:19 am (UTC)Criticism of input-subsystem-security comes full circle
Date: 2013-08-30 01:40 pm (UTC)no subject
Date: 2013-08-31 12:50 pm (UTC)Typical user, or typical scenario for a broad spectrum of users?
Date: 2013-09-01 04:37 am (UTC)Long answer, somewhat facetious: if you look at a 'typical' user, they're running Windows on a PC, or they're running iOS on a tablet-slash-smartphone. They are at no risk from this security flaw.
If you look at a typical Linux user, or even a typical Ubuntu user, they are running a stock distro, and again are at no risk due to this flaw.
The actual *target* user of this patch is the technically-savvy, bleeding edge brave, willing and ready to debug horrible problems person. Therefore, the typical *scenario* for that broad spectrum of endusers (albeit drawn from a very small niche population) is that they will be downloading the master branch of Mir from git, to test it out.
There are some cases where they can be safe:
1. they create a special install for testing Mir, either on a usbkey or in a virtual machine, and therefore create a test-uid and test-passwd, such as username==u and password=p. That info might get released into the interwebs, but nobody would care.
2. they test Mir with their network cable unplugged (be it a physical one or a disabled virtual nic), and use some other machine for non-Mir tasks. In that case, even if they accidentally type in a secret passwd, which is then accidentally sent to the X session, it cannot go out over the network, so they are still fine.
3. they test Mir in a reasonably cursory fashion, running a few benchmarks and opening a few apps to kick the tires, but either don't ever open an IM session, or don't ever open a VT session (or at least don't have those open simultaneously and catastrophically).
(Probably more ways to be safe exist.)
There is really only one way in which this flaw can be a problem:
4. they test Mir by installing it onto their primary devbox, and they use this box-with-Mir as their primary machine for everyday tasks. In other words, they install Mir for *beta* testing purposes, and try to use it as they would normally use Linux. Under that sort of scenario, sooner or later, they are prolly going to have IRC or Pidgin or somesuch open in their gui session, and decide to use ctrl+alt+F4 or similar to switch over to a VT console for something, while meanwhile back in the GUI session their password just got sent out in the clear over the network.
You can avoid the trouble, if you are testing Mir, by not using it (yet) for *beta* testing purposes. Even better, you can test it from within a virtual machine environment (easily wiped when a new upgrade comes out or when you want to try an alternative config/installation/whatnot), and specify harmless username=u and password=p credentials for login to that VM, and ideally disable the virtual NIC, while you're at it.
So at the end of the day, even most people testing Mir are never going to get caught out by this security hole. It is not a real-world concern, in and of itself, more or less. What MJG is complaining about is that there was a public request for testing, and a tiny footnote about some security risk. That's not acceptable -- either fix the security risk *before* you invite people to test, or put the risk in HUGE CAPITALS at the top of your request, so nobody will get surprised. (Being well aware of the risk, they'll use the VM approach, not the beta-tester one, for instance.)
Re: Typical user, or typical scenario for a broad spectrum of users?
Date: 2013-09-01 10:11 am (UTC)Quite obviously this bug is not a risk to anyone not running Ubuntu or anyone running one of the current release versions of Ubuntu. We're talking about people who are running 13.10 and who have installed Mir either from the packages in universe or from the testing PPA.
You make the assumption that that's inevitably someone who has a certain tech profile. But in fact, Ubuntu alphas are these days generally stable enough that even a moderately skilled user can install and use them without strong impact on their day-to-day activity -- and frankly, it's nice to be able to help one's distro of choice by testing in this way and making sure that the (generally minor) issues that do arise get reported.
But someone like this -- like me, for example -- won't necessarily understand the details of the risk of this particular Mir bug. In my case: I log in as a single user, I browse the web, check email, etc., do some programming work, some writing with LaTeX and LibreOffice, have some chats with Empathy ... but I've no idea what it means to open a VT. Is it the same as opening the regular terminal app with Ctrl-Alt-T or something different? Am I at risk because I'm running Guake in the background at the same time as typing other stuff in another Gnome Terminal window? I've never hit Ctrl-Alt-f1 or Ctrl-Alt-f7 or Ctrl-Alt-fAnything in all my time of using Ubuntu. If I don't do this, am I safe from the security implications of this bug?
All these (fairly naive) questions reasonably prove your point about Canonical not doing a good enough job of communicating the risks, but I'm not sure they are adequately addressed by your response either. Maybe you felt that my original question was facetious too -- it wasn't intended to be, it was a genuine concern about what set of activities are subject to risk.
And no, it's not your job to make up for Canonical's failures, but you did stress the security implications of this bug, so I don't think it's unreasonable to ask you to clarify what you mean :-)
Re: only users running Xmir *and* using VTs *and* chat apps are impacted
Date: 2013-09-03 01:49 am (UTC)1. The person answering you, here and also above, is not the same as the person (mjg) who writes this blog. I'm just another reader, like you.
2A. Part of the reason that I felt the urge to be facetious was because your posting included some embedded assumptions. There is no frustration on my part with the 'community mgmt' side of this bug, because a) the bug is not in my code, and b) the community is not my own, in the sense you imply -- I neither develop Mir, nor use it, as yet (ditto for wayland as yet). I can assume much the same of mjg, though perhaps it is better to let him speak for himself: he does not work on mir, nor for canonical... he used to work for redhat, and nowadays mostly reverse-engineers proprietary bios stuff, from what I can tell. We are both interested in the Mir project, and in how canonical will handle it in the future, because we both care about the future of Linux.
2B. However, the *main* reason that I was somewhat facetious in my answer is because I thought your question was too incomplete to answer properly (which I suppose is unworthy of me in some realm of politeness... but if I do not express frustration then how would you realize there was even a problem, albeit a minor one, in the first place?) You did not specify what you meant by "typical user". You did not specify what you meant by "does some work". You did not specify any details about your concerns, that would allow me to give you a correct and non-facetious answer. See also, ESR's guide to smart questions. So, I gave you a somewhat facetious answer, starting with the statistically typical user, who is running win8, and cursing their luck.
3. Your longer explanation of your personal situation gives me enough clues to answer your real question: will this bug in Mir impact *you* given the way you work? No, you are safe. Even if you are running the pre-13.10 distro of some sort, with Mir and Xmir installed from universe, as the title of the mjg blogpost clearly says, this security problem only impacts people that use VTs, aka Ctrl+Alt+Fwhatever, *and* have chat-sessions running foreground in their Xmir session. You run chat sessions, you have Xmir (or perhaps are still thinking about testing it), but you don't use VTs.
4A. For your own edification, and anybody else reading the comments later, I'll give the concise overview of How Many Ways Can I Get To The Command Line Under Ubuntu, subject to limitations on my own knowledge. Nowadays, when you boot a desktop Linux distro, you immediately start working in Unity under X -- in other words, the GUI. There is a shortcut, which I believe is ubuntu-specific, where you hit Ctrl+Alt+t which opens up a window, inside which you see a command line prompt, where you can type command lines stuff, like grep and ls and all the other traditional Unix-like commands from the 1970s. This is not the only way to open such a thing: you can also hit the winkey, type xterm, and hit enter. More or less the same thing happens, although the details under the hood differ slightly (and the background color may differ as a visual indicator of what is happening). Normally, those are the only ways that the typical ubuntu enduser will interact with a cmdln.
4B. Of course, that's not the only way to get cmdln access. Assuming your machine has an sshd server running, an a known IP address (or even a domain name), you can usually walk away from your desktop, open up an ssh client on some other machine (ssh on Linux or PuTTY on windows or whatnot), and connect back to your desktop securely. You don't see the GUI portion of your desktop Ubuntu this way, unless you are doing ssh tunneling of a VNC connection or somesuch, but you do get cmdln access. Remotely! Nice.
4C. Walking back to your ubuntu PC again, and hit Ctrl+Alt+F4, and something Completely Different will happen. Your screen will change from 1080p mode down to something like an 80x25 vt100-style display-mode, and you will have stark white text (in an ugly font) on a stark black background. Welcome back to 1969: this is more or less how Kernighan and Richie logged into their original UNIX boxen. These are the VTs that were mentioned. By default, they are loaded when the kernel boots, and most endusers never need them, or indeed are even aware they are there. We used F4, so we're in VT#4. You can also switch over to VT5, which is a different login-session (logged out by default just like VT4 was). Your beautiful Unity & X stuff is not gone, by the way -- just hit Ctrl+Alt+F7 to return to the GUI session. You can think of the VTs as a primitive sort of "tabbed" xterms, more or less. They are mostly used as a last-resort fallback, when the X session is hung, and you need to get into the cmdln to restart everything, or something like that. Handy, if you are debugging a problem in Xmir, say.... oops!
4D. So, those are the major ways one would normally get access to the cmdln, which is hidden underneath the pretty facade. There are some less-well-known ways: when booting, hold down shift to get to GRUB, and there is an option to drop to a GRUB shell (this is far more crippled than a normal ubuntu terminal session however). You can also, from that same GRUB menu, pick the recovery option, and tell it you want to drop to a root shell, in which case you will be logged into the kernel as the sole VT, with no ctrl+alt+F7 at all. Of course, if you can boot the system from usb or dvdrw or pxe or similar, you can get access to a cmdln from those OSes (and browse the internal drives assuming they are not encrypted). You can even go *really* old-school, and hook up an rs232 console during boot ... or be a bit wimpier and hook up a usb equivalent thereof. Rarely, usually only on high end servers, there is sometimes an IPMI-style chip on the motherboard, which allows you to get a limited form of xterm access to the PC, even when the rest of the system is nominally powered down; cool!
4E. Combinations are always a possibility: you can be logged into your machine, simultaneously, with ctrl+alt+t running, with xterm in another window, logged into VT#4, also logged into VT#5, ssh'd in from a nearby Win7 box, ssh'd in from a nearby OSX box, ssh'd in from a nearby Android tablet, running a serial console link, *and* sending IPMI packets.
So, we've gone pretty far afield, time to bring us back to the subject at hand. As the titlebar says, this security hole only impacts you if you are running Xmir now (prior to an official release of an ubuntu distro containing it which is going to be 13.10 unless a catastrophe happens), and if you also sometimes use VTs aka Ctrl+Alt+F4 and friends.
The request for testing -- note the stuff at the bottom talking about bug #1192843 and passwords -- but methinks there was a typo and the bugnum and the description are not actually on the appropriate lines -- https://lists.ubuntu.com/archives/ubuntu-devel/2013-August/037572.html
The updated instructions, now with the security problem right at the top, just as it should be -- https://wiki.ubuntu.com/Mir/Installing
On the other hand, the *wiki* instructions don't mention the security hole at all -- http://unity.ubuntu.com/mir/installing_prebuilt_on_pc.html
The bug itself -- was marked as fixed briefly, but was reopened by RAOF (one of the key Mir developers) as of 2013-09-02 for the unity compositor -- https://bugs.launchpad.net/xmir/+bug/1192843
So, to wrap up, although I may not be a "member of the community" that is involved in developing and testing Mir at the moment, I'm definitely involved in the community that is interested in preserving and promoting freedom. Part of that means being responsible when you release: if you have a known security hole, you fix it before you release, or you MAKE SURE ANYBODY INSTALLING your software knows about it. Using allcaps, if necessary. :-)
Canonical is interested in getting Mir into the wild, so they can have it be as fully tested as possible. (This is known as the new-jersey-slash-worse-is-better philosophy, in contrast with west-coast-slash-the-right-thing philosophy wayland is using. Google these terms if you don't think they are fair; C and UNIX are key examples of the former approach.) The approach is fine, release early and release often is a good methodology. But there is a difference between releasing something that is only partially finished, with known bugs, and missing features... versus releasing something with a known security hole, that could end up giving your testers a security compromise. One improves community, the other detracts from it. Anyhoo, in the sense of community, if this humongous post has not cleared things up for you, ask away. As long as mjg does not mind, I'll try and answer what you want to find out.
Re: only users running Xmir *and* using VTs *and* chat apps are impacted
Date: 2013-09-03 05:45 am (UTC)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.
Hmm...
Date: 2013-09-01 09:28 pm (UTC)It'll go over about as well as a ton of bricks dropped on users heads like all of their other projects, so it will be a net win for everyone else.