openssh bugs - May 2024 - [Bug 3695] New: X11 forwarding via UNIX socket instead of 127.0.0.1

https://bugzilla.mindrot.org/show_bug.cgi?id=3695

            Bug ID: 3695
           Summary: X11 forwarding via UNIX socket instead of 127.0.0.1
           Product: Portable OpenSSH
           Version: 9.7p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: kolAflash at kolahilft.de

With "-X" SSH forwards X11 by listening to a TCP port on the
server's
localhost IP. Usually TCP 127.0.0.1:6010 for the first client.

127.0.0.1 isn't highly secure. Other users on the same host can connect
to it. And even JavaScript code from arbitrary websites running in a
local web browser can do certain connections to localhost.
https://developer.chrome.com/blog/private-network-access-update?hl=en
https://utcc.utoronto.ca/~cks/space/blog/web/ChromePrivateNetBlocks
https://bugzilla.mozilla.org/show_bug.cgi?id=354493
(with some luck the web browsers close that door in the next couple of
years...)

For X11 there is some authentication via the ~/.Xauthority file. But
I'm wondering why a UNIX socket is not being used instead. Locally X11
usually connects via a UNIX socket /tmp/.X11-unix/X0 which is properly
protected by file permissions. So really only the user himself can
connect to it. I'd guess that's much more secure than relying on
.Xauthority protecting the TCP socket.

---> So why not use a UNIX socket for X11 forwarding?



P.S.

I don't have much experience with Wayland. But it looks like Waypipe is
also using UNIX sockets for Wayland forwarding.
https://gitlab.freedesktop.org/mstoeckl/waypipe
https://mstoeckl.com/notes/gsoc/blog.html

You can manually try this out:
  ssh -R /tmp/.X11-unix/X1:/tmp/.X11-unix/X0 USER at HOST
  DISPLAY=:1 xterm
  rm -Iv /tmp/.X11-unix/X1
You have to manually remove /tmp/.X11-unix/X1 afterwards, because SSH
doesn't to that and won't create a new socket file on the next
connection if the old one still exists. There's a switch
StreamLocalBindUnlink=yes but it only works for forwarding the other
way around with -L instead of -R.
QUESTION:
Could this be fixed too? It's quite annoying to delete the socket file
manually. Or is there a certain reason why this must not be removed
automatically?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3695

--- Comment #1 from kolAflash at kolahilft.de ---
Recent developments:

https://lwn.net/Articles/984838/
> 0.0.0.0 Day:
> Exploiting Localhost APIs From the Browser (Oligo Security)
Turns out Unix (Linux, macOS) maps requests to 0.0.0.0/32 also to
127.0.0.1.


WORKAROUND SSH:
Forward X via UNIX socket instead of IP. (bash code for Debian-12)

remote_disp="$(shuf -i1-10000 -n1)"

ssh -t -R
/tmp/.X11-unix/X${remote_disp}:/tmp/.X11-unix/X"${DISPLAY:1}"
"${@}" env "DISPLAY=:${remote_disp}" bash -c "bash; rm
-Iv
/tmp/.X11-unix/X${remote_disp}"


WORKAROUND BROWSER:
I'm now running my browser in a cgroup which I deny access to these
addresses. (bash code)

systemd-run --user --scope --slice=no_localhost_net WEBBROWSER

# run with $CMD "iptables" and "ip6tables"
# for $IP 127.0.0.0/8 and 0.0.0.0/32 and ::1/128
$IPTABLES -A OUTPUT -p tcp --destination $IP -m cgroup --path
'user.slice/user-${UID}.slice/user@${UID}.service/no_localhost_net.slice'
-j REJECT

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3695

--- Comment #2 from kolAflash at kolahilft.de ---
P.S.: IPv6 ::/128 maps to ::1/128 on Unix (Linux/macOS)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.