The RandR extension in XFree86 4.2.0, X.Org X Window System (aka X11 or X) X11R6.7, and X.Org Server (aka xserver and xorg-server) before 1.16.3 allows remote authenticated users to cause a denial of service (out-of-bounds read or write) or possibly execute arbitrary code via a crafted length or index value to the (1) SProcRRQueryVersion, (2) SProcRRGetScreenInfo, (3) SProcRRSelectInput, or (4) SProcRRConfigureOutputProperty function.

The Render extension in XFree86 4.0.1, X.Org X Window System (aka X11 or X) X11R6.7, and X.Org Server (aka xserver and xorg-server) before 1.16.3 allows remote authenticated users to cause a denial of service (out-of-bounds read or write) or possibly execute arbitrary code via a crafted length or index value to the (1) ProcRenderQueryVersion, (2) SProcRenderQueryVersion, (3) SProcRenderQueryPictFormats, (4) SProcRenderQueryPictIndexValues, (5) SProcRenderCreatePicture, (6) SProcRenderChangePicture, (7) SProcRenderSetPictureClipRectangles, (8) SProcRenderFreePicture, (9) SProcRenderComposite, (10) SProcRenderScale, (11) SProcRenderCreateGlyphSet, (12) SProcRenderReferenceGlyphSet, (13) SProcRenderFreeGlyphSet, (14) SProcRenderFreeGlyphs, or (15) SProcRenderCompositeGlyphs function.

The XVideo extension in XFree86 4.0.0, X.Org X Window System (aka X11 or X) X11R6.7, and X.Org Server (aka xserver and xorg-server) before 1.16.3 allows remote authenticated users to cause a denial of service (out-of-bounds read or write) or possibly execute arbitrary code via a crafted length or index value to the (1) SProcXvQueryExtension, (2) SProcXvQueryAdaptors, (3) SProcXvQueryEncodings, (4) SProcXvGrabPort, (5) SProcXvUngrabPort, (6) SProcXvPutVideo, (7) SProcXvPutStill, (8) SProcXvGetVideo, (9) SProcXvGetStill, (10) SProcXvPutImage, (11) SProcXvShmPutImage, (12) SProcXvSelectVideoNotify, (13) SProcXvSelectPortNotify, (14) SProcXvStopVideo, (15) SProcXvSetPortAttribute, (16) SProcXvGetPortAttribute, (17) SProcXvQueryBestSize, (18) SProcXvQueryPortAttributes, (19) SProcXvQueryImageAttributes, or (20) SProcXvListImageFormats function.

The XInput extension in X.Org X Window System (aka X11 or X) X11R4 and X.Org Server (aka xserver and xorg-server) before 1.16.3 allows remote authenticated users to cause a denial of service (out-of-bounds read or write) or possibly execute arbitrary code via a crafted length or index value to the (1) SProcXChangeDeviceControl, (2) ProcXChangeDeviceControl, (3) ProcXChangeFeedbackControl, (4) ProcXSendExtensionEvent, (5) SProcXIAllowEvents, (6) SProcXIChangeCursor, (7) ProcXIChangeHierarchy, (8) SProcXIGetClientPointer, (9) SProcXIGrabDevice, (10) SProcXIUngrabDevice, (11) ProcXIUngrabDevice, (12) SProcXIPassiveGrabDevice, (13) ProcXIPassiveGrabDevice, (14) SProcXIPassiveUngrabDevice, (15) ProcXIPassiveUngrabDevice, (16) SProcXListDeviceProperties, (17) SProcXDeleteDeviceProperty, (18) SProcXIListProperties, (19) SProcXIDeleteProperty, (20) SProcXIGetProperty, (21) SProcXIQueryDevice, (22) SProcXIQueryPointer, (23) SProcXISelectEvents, (24) SProcXISetClientPointer, (25) SProcXISetFocus, (26) SProcXIGetFocus, or (27) SProcXIWarpPointer function.

The GLX extension in XFree86 4.0, X.Org X Window System (aka X11 or X) X11R6.7, and X.Org Server (aka xserver and xorg-server) before 1.16.3 allows remote authenticated users to cause a denial of service (out-of-bounds read or write) or possibly execute arbitrary code via a crafted length or index value to the (1) glXDispRender, (2) glXDispRenderLarge, (3) glXDispSwapVendorPrivate, (4) glXDispSwapVendorPrivateWithReply, (5) setclientinfo, (6) glXDispSwapSetClientInfoARB, (7) DoSwapInterval, (8) DoGetProgramString, (9) DoGetString, (10) glXDispSwapRenderMode, (11) glXDispGetCompressedTexImage, (12) glXDispSwapGetCompressedTexImage, (13) glXDispFeedbackBuffer, (14) glXDispSwapFeedbackBuffer, (15) glXDispSelectBuffer, (16) glXDispSwapSelectBuffer, (17) glXDispFlush, (18) glXDispSwapFlush, (19) glXDispFinish, (20) glXDispSwapFinish, (21) glXDispReadPixels, (22) glXDispSwapReadPixels, (23) glXDispGetTexImage, (24) glXDispSwapGetTexImage, (25) glXDispGetPolygonStipple, (26) glXDispSwapGetPolygonStipple, (27) glXDispGetSeparableFilter, (28) glXDispGetSeparableFilterEXT, (29) glXDispGetConvolutionFilter, (30) glXDispGetConvolutionFilterEXT, (31) glXDispGetHistogram, (32) glXDispGetHistogramEXT, (33) glXDispGetMinmax, (34) glXDispGetMinmaxEXT, (35) glXDispGetColorTable, (36) glXDispGetColorTableSGI, (37) GetSeparableFilter, (38) GetConvolutionFilter, (39) GetHistogram, (40) GetMinmax, or (41) GetColorTable function.

Multiple integer overflows in the GLX extension in XFree86 4.0, X.Org X Window System (aka X11 or X) X11R6.7, and X.Org Server (aka xserver and xorg-server) before 1.16.3 allow remote authenticated users to cause a denial of service (crash) or possibly execute arbitrary code via a crafted request to the (1) glXDispReadPixels, (2) glXDispSwapReadPixels, (3) glXDispGetTexImage, (4) glXDispSwapGetTexImage, (5) GetSeparableFilter, (6) GetConvolutionFilter, (7) GetHistogram, (8) GetMinmax, (9) GetColorTable, (10) glXGetAnswerBuffer, (11) GLXGETANSWERBUFFER, (12) glXMap1dReqSize, (13) glXMap1fReqSize, (14) Map2Size, (15) glXMap2dReqSize, (16) glXMap2fReqSize, (17) glXImageSize, or (18) glXSeparableFilter2DReqSize function, which triggers an out-of-bounds read or write.

The SProcXFixesSelectSelectionInput function in the XFixes extension in X.Org X Window System (aka X11 or X) X11R6.8.0 and X.Org Server (aka xserver and xorg-server) before 1.16.3 allows remote authenticated users to cause a denial of service (out-of-bounds read or write) or possibly execute arbitrary code via a crafted length value.

Multiple integer overflows in X.Org X Window System (aka X11 or X) X11R1 and X.Org Server (aka xserver and xorg-server) before 1.16.3 allow remote authenticated users to cause a denial of service (crash) or possibly execute arbitrary code via a crafted request to the (1) ProcPutImage, (2) GetHosts, (3) RegionSizeof, or (4) REQUESTFIXEDSIZE function, which triggers an out-of-bounds read or write.

The DBE extension in X.Org X Window System (aka X11 or X) X11R6.1 and X.Org Server (aka xserver and xorg-server) before 1.16.3 allows remote authenticated users to cause a denial of service (out-of-bounds read or write) or possibly execute arbitrary code via a crafted length or index value to the (1) ProcDbeSwapBuffers or (2) SProcDbeSwapBuffers function.

The SProcXCMiscGetXIDList function in the XC-MISC extension in X.Org X Window System (aka X11 or X) X11R6.0 and X.Org Server (aka xserver and xorg-server) before 1.16.3 allows remote authenticated users to cause a denial of service (out-of-bounds read or write) or possibly execute arbitrary code via a crafted length or index value.

X.Org X Window System (aka X11 and X) X11R5 and X.Org Server (aka xserver and xorg-server) before 1.16.3, when using SUN-DES-1 (Secure RPC) authentication credentials, does not check the return value of a malloc call, which allows remote attackers to cause a denial of service (NULL pointer dereference and server crash) via a crafted connection request.

xscreensaver (aka Gnome-XScreenSaver) in Sun Solaris 9 and 10, OpenSolaris snv109 through snv122, and X11 6.4.1 on Solaris 8 does not properly handle Accessibility support, which allows local users to cause a denial of service (system hang) by locking the screen and then attempting to launch an Accessibility pop-up window, related to a regression in certain Solaris and OpenSolaris patches.

The Abstract Window Toolkit (AWT) implementation in Sun Java SE 6 before Update 15 on X11 does not impose the intended constraint on distance from the window border to the Security Warning Icon, which makes it easier for context-dependent attackers to trick a user into interacting unsafely with an untrusted applet.

XScreenSaver in Sun Solaris 9 and 10, OpenSolaris before snv120, and X11 6.4.1 for Solaris 8, when the Xorg or Xnewt server is used, allows physically proximate attackers to obtain sensitive information by reading popup windows, which are displayed even when the screen is locked, a different vulnerability than CVE-2009-1276.

Format string vulnerability in the LogVHdrMessageVerb function in os/log.c in X.Org X11 1.11 allows attackers to cause a denial of service or possibly execute arbitrary code via format string specifiers in an input device name.

On Wed, 2023-10-18 at 13:25 -0500, Grant Taylor wrote: I think that this is more a problem with X11 security than it is a problem specific to Mozilla / Firefox. Also a problem with shell security. If you paste something with line breaks into bash, it executes them. If you paste the same into fish, it doesn't (it'll display the multi-line input and expect you to hit the enter key to execute it as a command).

The importance of mutual authentication: Local Privilege Escalation in X11

While X11 servers authenticate their clients, X11 clients do not authenticate the server. This can be exploited to take control of an X application by impersonating the server it is expecting to connect to.

Exploiting this vulnerability is not trivial. Typically, the X11 socket is either in /tmp/.X11-unix (which is sticky) or in the abstract namespace. Therefore, it is necessary to wait until the legitimate X server has exited and the socket is unlinked. Many graphical applications exit if their connection to the X server is lost, so a typical desktop session is either impossible or difficult to exploit. If the socket has already been bound, X will fail to start. If this prevents client programs from starting, planting a “poisoned” X socket won’t work either, although it will create a denial of service condition.

It is, however, possible to exploit any X application that (erroneously) starts after the X server has already exited. There are several potential ways this can happen:

- On single-seat graphical workstations, the DISPLAY environment variable is virtually always set to :0, as there is generally only one X server running at a time. Therefore, users may (erroneously) write scripts that assume this to be the case, and start them from outside of a graphical session (such as via cron or systemd).

- There is a race condition during session exit: if the X server shuts down and unlinks its socket, but another program has already started to execute an X client application, there is a window during which an attacker can bind to the previous X socket before the client tries to connect to it.

Potential Fixes:

Fixing this vulnerability requires that X clients authenticate the server, or that the X server socket is protected against spoofing. Three potential methods of doing so follow, but there may very well be others. Only the first addresses the denial of service vulnerability, but all three prevent privilege escalation.

Placing the X socket in a secure directory

X11 is usually used with AFUNIX sockets. In this case, performing the attack requires that either the directory containing the X socket be writable by an attacker, or that the abstract namespace is in use. If neither condition is met, the attack is thwarted. In this case, the server is implicitly authenticated by being able to write to a location on the file system. On systems other than macOS, placing the X socket in a non-default directory requires changes to X. On Linux, this also requires that abstract sockets be disabled in the X client libraries.

A user’s home directory is a safe location on virtually all systems. /run/user/$UID is a good choice when it is secure and available, such as on systemd-based Linux distributions. /tmp/.X11-unix can be made safer by ensuring that it is created before any untrusted code runs and ensuring that untrusted code cannot write to it. For example, it could be owned by root and have 0755 permissions. For this to be effective, untrusted code must not be allowed to start if creating /tmp/.X11-unix fails; this can be enforced by dropping into single-user mode in this case. Furthermore, if the standard location for lock files (/tmp/.X-lock) is used, there is still a potential denial of service, as anyone can create a lock file and prevent the legitimate server from starting.

I recommend using /run/user/$UID when it exists, is owned by the user, and has 0700 permissions. Otherwise, a user’s home directory (or subfolder thereof) is an acceptable fallback. I do not recommend continuing to use /tmp/.X11-unix, due to the risks outlined above.

Explicit checking of peer credentials

When AFUNIX sockets are used (the most common case), the client can check the server’s credentials using SOPEERCRED, SCMCREDENTIALS, or another platform-specific mechanism. The X.org server already has the code to check a peer’s credentials, and can be configured to use this instead of ~/.Xauthority. The set of trusted user IDs is system-dependent. Generally, it should include the superuser and the UID of the X client, but on some systems (such as OpenBSD), the X server runs as a dedicated non-privileged user, which may also need to be included in the trusted UID list.

Cryptographic authentication

For both AFUNIX and TCP transports, it is possible to use cryptographic authentication. This must be designed carefully to prevent replay attacks. One such protocol (which has not been audited) is as follows. It uses the X11 cookie K, a MAC, and distinct, equal-length domain-separation strings S1 and S2.

1. Client generates a 32-byte random token (CR) and sends it to the server.

2. The server generates a 32-byte random number (SR). It computes Sauth := MAC(K, S1 || CR || SR || serversockaddr || clientsockaddr) and sends Sauth || SR to the client.

3. The client checks if Sauth was computed correctly. If not, it disconnects. If it was, the client computes Cauth := MAC(K, S2 || CR || SR || serversockaddr || clientsockaddr) and sends it to the server.

4. The server checks that Cauth was computed correctly. If it was, the client is authenticated; otherwise, the server disconnects.

Note that CR and SR must be generated randomly for every connection. Reasonable choices for the MAC include Blake2b, Blake3, and HMAC-SHA2. Length fields are omitted because the lengths of CR and SR are fixed, and the length of a struct sockaddrstorage can be determined from its address family. AFUNIX sockaddrs MUST be NUL-terminated. For AFUNIX sockets, this is only safe if anonymous AFUNIX sockets have unique addresses, which I believe to be the case on Linux.

The X11 protocol does not provide any encryption or authentication of messages. Therefore, users who can sniff network traffic can still read all X protocol traffic over TCP, and users who can inject packets can tamper with such traffic. On OpenBSD, both require full root privileges, so this is not a problem in the default configuration. On Linux and illumos, packet sniffing and injection does not require full root privileges, although it requires privileges that ordinary users typically do not have. X over TCP is usually used in the context of SSH forwarding, and switching SSH forwarding to use AFUNIX would avoid this problem.

Timeline

2019-10-25: Reported to openssh () openssh com as a vulnerability in OpenSSH X11 forwarding.

2019-10-31: The OpenSSH developers states that this is a bug in X11, not in OpenSSH.

2019-11-01: I report this bug to xorg-security () lists x org

2019-11-04: Reply stating that this scenario is possible, but unlikely, and that fixing it would require major changes to the X protocol.

2019-11-04: I reply that SCMCREDENTIALS and friends can be used for AFUNIX sockets.

2019-11-23 through 2019-11-25: A new X authorization mechanism is suggested by the X developers. Private discussions about the form this will take.

2020-01-23: I ask for an update and mention that AFUNIX sockets are vulnerable as well.

2020-02-02: I ask for an update and mention that over 90 days have elapsed.

2020-10-08: I write an advisory and state that I intend to publicly disclose it.

2020-10-08 through 2020-10-29: Discussion of the vulnerability leads to changes in the advisory text.

2020-11-02: Vulnerability sent to distros () vs openwall org

2020-11-03: Marcus Meissner <meissner () suse de> confirms that distros () vs openwall org has received the message.

2020-11-05: I email xorg-security () lists x org asking if a fix will be available.

2020-11-06: Alan Coopersmith <alan.coopersmith () oracle com> states that there are too few people working on X for upstream to create a fix prior to disclosure.

2020-11-06: Red Hat Product Security assigns CVE-2020-25697 to this issue.

2020-11-09: Full disclosure

Sincerely,

Demi M. Obenour