Fedora Linux Looks To Close Another "Large Attack Surface" With The X.Org Server
Fedora is looking at disallowing X.Org/XWayland clients of difference CPU endianness from connecting to the X.Org Server. Such a combination of different endianness between the X.Org Server and clients is rather rare these days but is yet another "large attack surface" of the X.Org Server that needs addressing.
A Fedora 38 change proposal has been filed to prohibit byte-swapped X.Org Server clients. There is also a change pending for the upstream X.Org Server that would also disable byte-swapped clients.
Red Hat's Peter Hutterer explained in the F38 change proposal:
For the upstream X.Org Server there is a new merge request authored by Peter to disallow byte-swapped clients by default. For Fedora and with the proposed upstream change, the current behavior of allowing byte-swapped clients could be restored via the "AllowSwappedClients" server flag or the "+byte-swapped-clients" option.
This security change was originally proposed a year ago, "The swapped-endian support in X is a massive amount of very rarely used code. Since it is so rarely used, and hand-written, it is quite likely to have serious bugs that have gone undiscovered. Some of these bugs may very well have security implications."
Again, it would be rather rare for anyone in a modern environment to be affected by this change, but in turn is another security improvement for this aging and massive codebase that has seen an increasing number of security advisories issued over the past decade. If you do find yourself connecting from an x86_64 system to an IBM s390x or PPC64 server for remote X11 use of graphical applications, besides using the proposed options for allowing byte-swapped clients there is always the other option of using alternative solutions like VNC.
A Fedora 38 change proposal has been filed to prohibit byte-swapped X.Org Server clients. There is also a change pending for the upstream X.Org Server that would also disable byte-swapped clients.
Red Hat's Peter Hutterer explained in the F38 change proposal:
"X server implementations (e.g. Xorg and Xwayland) allow clients with an endianness different to that of the server to connect. Protocol messages to and from these clients are byte-swapped by the X server. However, the code in the X server that does this is virtually untested, providing a large attack surface for malicious clients. One needs to only look at e.g. this X.Org security advisory and count the SProc mentions for an indication on how bad this is. A simple solution to remove this attack surface is to prohibit clients with a different endianness. These clients will simply fail, in a matter similar to failing to authenticate against an X server.
The use-case for clients with different endianness is very niche. It was common in the 1980s when X was originally developed but at this point a vanishingly small number of users run clients and X servers on different machines, let alone on different machines with different endianness. I'd be surprised if Fedora had any users requiring this feature."
For the upstream X.Org Server there is a new merge request authored by Peter to disallow byte-swapped clients by default. For Fedora and with the proposed upstream change, the current behavior of allowing byte-swapped clients could be restored via the "AllowSwappedClients" server flag or the "+byte-swapped-clients" option.
This security change was originally proposed a year ago, "The swapped-endian support in X is a massive amount of very rarely used code. Since it is so rarely used, and hand-written, it is quite likely to have serious bugs that have gone undiscovered. Some of these bugs may very well have security implications."
Again, it would be rather rare for anyone in a modern environment to be affected by this change, but in turn is another security improvement for this aging and massive codebase that has seen an increasing number of security advisories issued over the past decade. If you do find yourself connecting from an x86_64 system to an IBM s390x or PPC64 server for remote X11 use of graphical applications, besides using the proposed options for allowing byte-swapped clients there is always the other option of using alternative solutions like VNC.
168 Comments