AI_ONLY_REPORT
package: openssh-9.9p1-22.el10_2
------
Summary: Local MITM of X11 forwarding via preferred Linux abstract UNIX  
socket connection: a local unprivileged process on the Linux client host  
can hijack the client-side X11 forwarding connection by pre-binding the  
preferred abstract X socket name.
Requirements to exploit: An attacker needs local unprivileged code  
execution on the Linux host running the OpenSSH client, client-side X11  
forwarding enabled (`-X`, `-Y`, or equivalent configuration), a local  
`DISPLAY` that resolves to a UNIX-domain X socket such as `:0` or `unix:0`,  
and a forwarded X11 connection to be opened while the attacker has  
pre-bound the matching abstract socket name.
Component affected: `openssh-9.9p1-22.el10_2`, client-side X11 forwarding  
code in `openssh-9.9p1/channels.c` (`connect_local_xsocket()`,  
`x11_open_helper()`).
Version affected: `openssh-9.9p1-22.el10_2`; reachable on Linux in the  
client-side X11 forwarding path when X11 forwarding is enabled and  
`DISPLAY` resolves to a local UNIX-domain X socket
Patch available: no released package fix established; proposed patch  
included below
Version fixed: unknown
Upstream coordination: Not notified.
CVSS: CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:H/I:L/A:N - 5.3 (MEDIUM)
AV:L - The attacker must already have local code execution on the Linux  
system running the OpenSSH client.
AC:H - Exploitation depends on a feature-specific client configuration,  
successful pre-binding of the matching abstract X11 socket, and a forwarded  
X11 connection actually being opened.
PR:L - An unprivileged local user account or equivalent local process  
execution is sufficient.
UI:R - A user must enable X11 forwarding and the session must trigger a  
forwarded X11 connection.
S:U - The impact stays within the client-side OpenSSH/X11 forwarding  
security scope.
C:H - A successful hijack can expose forwarded X11 traffic, including  
sensitive window contents and input; when real `xauth` data is available,  
the saved X11 authentication data may also be substituted into the hijacked  
stream.
I:L - The attacker can influence the X11 protocol stream presented to  
the forwarded application, but the demonstrated effect is narrower than  
general host compromise.
A:N - The issue does not require a direct availability impact to succeed.
Impact: Moderate. A successful attack can compromise the confidentiality of  
forwarded X11 traffic and allow some integrity impact on the forwarded  
session, but exploitation is limited to a local attacker on the client host  
and depends on the non-default, feature-specific condition that X11  
forwarding is enabled and used. Under Red Hat’s criteria, this is better  
classified as Moderate than Important because it is real but not easily  
exploitable in typical deployments.
Embargo: no
Reason: This is a local, configuration-dependent client-side issue with  
straightforward mitigation by disabling X11 forwarding where it is not  
required, and it does not present an easily exploitable remote compromise  
path.
Acknowledgement: Aisle Research
Vulnerability Details: This issue is in the OpenSSH client’s Linux X11  
forwarding path. When the client receives an X11 open request, the call  
path reaches `x11_connect_display()`, which parses `DISPLAY` and, for local  
UNIX-domain displays such as `:0` or `unix:0`, calls  
`connect_local_xsocket()`.
In the vulnerable path, Linux tries the abstract UNIX socket name before  
the filesystem socket:
```c
len = snprintf(buf + 1, sizeof (buf) - 1, _PATH_UNIX_X, dnr);
#ifdef linux
/* try abstract socket first */
buf[0] = '\0';
if ((ret = connect_local_xsocket_path(buf, len + 1)) >= 0)
return ret;
#endif
if ((ret = connect_local_xsocket_path(buf + 1, len)) >= 0)
return ret;
```
`_PATH_UNIX_X` resolves to `/tmp/.X11-unix/X%u`, so on Linux the first  
attempted endpoint is the abstract socket name  
`\0/tmp/.X11-unix/X<display>`. Because Linux abstract UNIX sockets are not  
mediated by filesystem permissions, an unprivileged local process can  
pre-bind that name and receive the forwarded X11 connection before the  
legitimate filesystem socket. The connection helper performs a direct  
`connect()` and does not verify peer credentials or ownership after the  
connection succeeds.
OpenSSH’s X11 spoofing logic validates the fake cookie received from the  
remote side, but it does not authenticate the local X11 endpoint. After the  
fake cookie check passes, the client replaces it with the saved X11  
authentication data:
```c
if (data_len != sc->x11_fake_data_len ||
timingsafe_bcmp(ucp + 12 + ((proto_len + 3) & ~3),
sc->x11_fake_data, sc->x11_fake_data_len) != 0) {
debug2("X11 auth data does not match fake data.");
return -1;
}
...
memcpy(ucp + 12 + ((proto_len + 3) & ~3),
sc->x11_saved_data, sc->x11_saved_data_len);
```
As a result, an attacker-controlled abstract socket can receive the  
forwarded X11 session first. Where real `xauth` data was obtained, the  
rewritten first packet will contain the saved X11 authentication data. If  
`xauth` data is unavailable, OpenSSH can fall back to generated fake data,  
which reduces credential-leak impact but does not prevent the connection  
hijack or interception of the forwarded X11 stream. The available evidence  
supports interception and limited manipulation of forwarded X11 sessions,  
not arbitrary code execution or privilege escalation in the client itself.
Steps to reproduce:
1. On a Linux system running the OpenSSH client, confirm the local display  
uses a UNIX-domain socket such as `:0` or `unix:0`.
2. Before opening a forwarded X11 connection, start a local unprivileged  
listener bound to the matching abstract socket name. For display `:0`:
```python
import socket
s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
s.bind("\0/tmp/.X11-unix/X0")
s.listen(1)
c, _ = s.accept()
print("accepted; first bytes:", c.recv(64).hex())
```
3. In another terminal, start an SSH session with X11 forwarding enabled:
```bash
ssh -X user@remote
```
4. From the remote shell, trigger an X11 application so that the client  
opens the forwarded X11 channel, for example:
```bash
xclock
```
5. Observe that the attacker listener accepts the connection and receives  
the initial X11 bytes before the legitimate filesystem socket  
`/tmp/.X11-unix/X0` is used.
6. Optional confirmation:
```bash
strace -f -e connect ssh -X user@remote
```
Expected result: tracing shows a successful `AF_UNIX` connect to the  
abstract socket name `\0/tmp/.X11-unix/X0` before any successful connect to  
`/tmp/.X11-unix/X0`.
Mitigation: Disable X11 forwarding on affected clients when it is not  
required, for example by avoiding `-X`/`-Y` and using `ForwardX11 no`. On  
shared Linux systems where untrusted local users or processes may be  
present, avoid relying on client-side X11 forwarding until a fix that  
prefers the filesystem X socket has been applied.
Proposed Fix: Prefer the filesystem X11 socket first, and retain Linux  
abstract sockets only as a compatibility fallback.
```diff
diff --git a/openssh-9.9p1/channels.c b/openssh-9.9p1/channels.c
@@ static int connect_local_xsocket(u_int dnr)
len = snprintf(buf + 1, sizeof (buf) - 1, _PATH_UNIX_X, dnr);
+	/* Prefer filesystem socket (permission/ownership mediated) */
+	if ((ret = connect_local_xsocket_path(buf + 1, len)) >= 0)
+		return ret;
#ifdef linux
-	/* try abstract socket first */
+	/* Abstract socket fallback for compatibility */
buf[0] = '\0';
if ((ret = connect_local_xsocket_path(buf, len + 1)) >= 0)
return ret;
#endif
-	if ((ret = connect_local_xsocket_path(buf + 1, len)) >= 0)
-		return ret;
error("connect %.100s: %.100s", buf + 1, strerror(errno));
return -1;
```
------
This report was generated using AI technology. Always review AI-generated  
content prior to use