Bug 64402

Summary:

XQueryKeymap() bypasses security-sensitive keyboard grabs

Product:

xorg

Reporter:

Daniel Richard G. <skunk>

Component:

Server/Input/Core

Assignee:

Xorg Project Team <xorg-team>

Status:

RESOLVED WONTFIX

QA Contact:

Xorg Project Team <xorg-team>

Severity:

enhancement

Priority:

medium

CC:

peter.hutterer, xorg_security

Version:

unspecified

Hardware:

x86-64 (AMD64)

OS:

Linux (All)

Whiteboard:

i915 platform:

i915 features:

Attachments:

Description	Flags
Proof-of-concept key-reading program	none

Description Daniel Richard G. 2013-05-09 20:35:43 UTC

Created attachment 79063 [details]
Proof-of-concept key-reading program

This is an issue that has affected XFree86/X.org for many years. It was first (to my knowledge) reported by Christopher Creutzig back in 1997 on Red Hat's linux-security list, without receiving any response:

    http://www.redhat.com/archives/linux-security/1997-October/msg00010.html

The subject was more recently touched upon in a non-security-related discussion of pointer grabs on an X.org list:

    http://lists.x.org/archives/xorg/2008-April/034772.html
    http://lists.x.org/archives/xorg/2008-April/034774.html

The issue: There are various instances of X applications performing a keyboard grab to allow secure entry of passwords/passphrases. "Secure," in this context, can mean both (1) preventing sensitive information from being entered into the wrong application, like an IRC client, and (2) preventing other X clients from capturing this information through the X API---keyloggers, in other words. (Keyloggers that work by other means, such as LD_PRELOAD or a kernel module, are naturally out of scope here.)

Examples of such applications include XTerm, with its "Secure Keyboard" mode, the various iterations of ssh-askpass, and PolicyKit. None of these, as far as I'm aware, claim to be robust to X-based keyloggers. The XTerm man page even lists these caveats:

    * The X input extension for instance allows an application to
      bypass all of the other (limited) authorization and
      security features, including the GrabKeyboard protocol.

    * The possibility of an application spying on your keystrokes
      is of particular concern when you want to type in a
      password or other sensitive data. The best solution to this
      problem is to use a better authorization mechanism than is
      provided by X.

    * It [Secure Keyboard mode] cannot ensure that there are no
      processes which have access to your X display that might be
      observing the keystrokes as well.

The XQueryKeymap() call currently provides a trivial means of bypassing XGrabKeyboard(). I'm attaching a proof-of-concept program that demonstrates this; it is a revised version of a PoC written by Mr. Creutzig. The only shortcoming of this approach is that it requires a tight polling loop---and even then, polling at 100Hz appears to be enough to capture real-world keystrokes while flying under the radar of top(1) and friends.

The second lists.x.org link above is the first of a handful of messages describing possible solutions for this, basically amounting to XQueryKeymap() et al. returning blank/bogus information when a grab is active to all clients except for the one holding the grab.

I should note that ssh-askpass (and possibly other programs) can also make use of XGrabServer(), which does appear to defeat an XQueryKeymap()-based keylogger. However, the practicality of this approach is questionable, given how the server grab prevents the program's own window from being displayed correctly.

Comment 1 Alan Coopersmith 2013-05-09 21:08:05 UTC

There is no such thing as a secure keyboard grab, and never has been.
The labeling of the xterm menu item as "secure keyboard" was a bug in
xterm that was fixed a number of years ago (bug #379 here). 
Any application thinking that grabbing the keyboard provides security
is mistaken and buggy.

The ability of XQueryKeymap to see keyboard state was known well before 1997,
as it was covered in the "Analysis of the X Protocol for Security Concerns"
published in 1996:
   http://www.x.org/releases/X11R7.7/doc/xorg-docs/Xserver/analysis.html
had proof of concept code published in 1995:
   http://web.archive.org/web/20010803132807/http://www.acm.vt.edu/~jmaxwell/programs/xspy/xspy.html
and a solution was provided in the X Security extension in 1996:
   http://www.x.org/releases/X11R7.7/doc/xextproto/security.html#Keyboard_Security

I'm tempted to simply close this as not a bug, as it's a long documented
limitation of the X11 protocol, with an extension already provided to fix,
but will leave it open for now for other X developers to chime in.

Comment 2 Daniel Richard G. 2013-05-09 21:44:55 UTC

Do you know of any existing apps using the X Security extension to protect keyboard input? I haven't seen any reference to this animal before.

(I recognize that XGrabKeyboard() is not advertised as providing a secure input path, which is why I filed this as an enhancement rather than a bug.)

Comment 3 Peter Hutterer 2013-05-09 22:30:59 UTC

I guess XACE is a useful reference to add here too:
http://www.x.org/releases/X11R7.5/doc/security/XACE-Spec.html

I'm closing this as WONTFIX. Don't take this as "we don't want this", read this as "we will never have the time to implement this", so we might as well shatter any hopes now before someone gets too attached to the idea.

Comment 4 Alan Coopersmith 2013-05-09 22:38:45 UTC

The only app I know of that uses the X security extension is OpenSSH, but
many users disable the security as being too painful.

Comment 5 Daniel Richard G. 2013-05-10 00:08:05 UTC

(In reply to comment #4)
> The only app I know of that uses the X security extension is OpenSSH, but
> many users disable the security as being too painful.

I see this has to do with the distinction between OpenSSH's -X and -Y options (and despite my expectation, nothing to do with the bundled gnome-ssh-askpass program). This thread has some more information, but little of it is positive:

    http://lists.freedesktop.org/archives/xdg/2008-December/010104.html

(In reply to comment #3)
> I guess XACE is a useful reference to add here too:
> http://www.x.org/releases/X11R7.5/doc/security/XACE-Spec.html

Which appears to be what SELinux uses.

> I'm closing this as WONTFIX. Don't take this as "we don't want this", read
> this as "we will never have the time to implement this", so we might as well
> shatter any hopes now before someone gets too attached to the idea.

Well, at least now, this is documented :-)  I'm not surprised; an issue old enough to buy cigarettes probably didn't get that way by escaping notice.

Just so that I understand: Is it that implementing Daniel Stone's suggested fix would be in itself non-trivial, or that plugging up all the avenues that a keylogger could use in the X API would be a wild-goose chase, or what?

Hypothetically speaking, if someone wanted to patch up ssh-askpass or the like to better protect against keyloggers, would it make architectural sense to develop a small XACE-based extension that can then be used by such programs?

(The idea I've heard tossed around to provide secure password entry is to start up a second X server, switch VT, show the dialog, then exit and switch back---giving a UI experience not unlike the Ctrl-Alt-Delete dialog in Microsoft Windows. It would be nice if there were a more lightweight approach that would yield a comparable degree of security.)

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.