On Wed, Dec 21, 2022 at 4:49 PM Ben Cotton <bcotton(a)redhat.com>
wrote:
>
>
https://fedoraproject.org/wiki/Changes/XServerProhibitsByteSwappedClients
>
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will only be implemented if approved
> by the Fedora Engineering Steering Committee.
>
> == Summary ==
> X server implementations (e.g. Xorg and Xwayland) will (by default) no
> longer allow clients with different endianess to connect.
>
> == Owner ==
> * Name: [[User:whot| Peter Hutterer]]
> * Email: peter.hutterer(a)redhat.com
>
>
> == Detailed Description ==
> <!-- Expand on the summary, if appropriate. A couple sentences
> suffices to explain the goal, but the more details you can provide the
> better. -->
>
> X server implementations (e.g. Xorg and Xwayland) allow clients with
> an endianess 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.
> [
https://www.x.org/wiki/Development/Security/Advisory-2014-12-09 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 endianess. These
> clients will simply fail, in a matter similar to failing to
> authenticate against an X server.
>
> The use-case for clients with different endianess 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
> endianess. I'd be surprised if Fedora had ''any'' users requiring
this
> feature.
>
> Note:
> * this only affects use-cases where the server runs on a little endian
> host and the client on a Big Endian host (or vice versa).
> * this is a change in '''the default behavior''' only and can
be
> changed via configuration options (for `Xorg`) and/or commandline
> arguments (all X servers).
> * this is a change in the upstream default behavior that Fedora will
> follow along with. This Change is primarily to increase the exposure.
>
>
> == Benefit to Fedora ==
>
> This change removes a large potential attack surface that can be used
> by malicious clients to expose memory locations, crash the X server
> and/or do other entertaining things malicious programs like to do.
>
> == Scope ==
> * Proposal owners:
> # Merge [
https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1029
> upstream PR]
> # Backport patch to Fedora's `xorg-x11-server` and
> `xorg-x11-server-Xwayland` packages
>
> * Other developers: This is labelled as system-wide change simply
> because it's a change in Xorg/Xwayland. It is otherwise self-contained
> in that no other packages need updating, '''unless''' they
want to
> opt-out of this default. Which is better left to system-specific
> configuration anyway.
>
> * Release engineering: This feature does not require coordination with
> release engineering
>
> * Policies and guidelines: N/A (not needed for this Change)
> * Trademark approval: N/A (not needed for this Change)
> * Alignment with Objectives:
>
> == Upgrade/compatibility impact ==
> For the ''extremely niche'' use-case of users that run X clients on
a
> remote machine with a different endianess, these clients will no
> longer be able to connect '''by default'''. For Xorg, the
following
> `xorg.conf.d` snippet will re-enable the old behavior:
>
> <pre>
> Section "ServerFlags"
> Option "AllowSwappedClients" "on"
> EndSection
> </pre>
>
> Wayland users (and thus Xwayland) need to employ compositor-specific
> configuration to pass the `+byteswappedclients` flag to Xwayland. At
> the time of writing, GNOME does not yet provide such a configuration.
>
> == How To Test ==
> To test the impact of this change, you need:
>
> * an X server running on a little endian architecture and an X client
> running on a Big Endian architecture (or the other way around)
> * set up the X server to accept remote connections, either via TCP or
> through SSH
> * run the X client which will fail to connect
>
> Alternatively, a test client is available in
> [
https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1029 the
> upstream PR]. This test client pretends to be BigEndian and will fail
> to connect when run against a little endian X server.
>
>
> == User Experience ==
> For virtually all users, there is no change in behavior.
>
> Users with X server and client on two different machines must add the
> `xorg.conf.d` snippet shown above on affected systems.
>
> == Dependencies ==
> No other RPMs depend on this change.
>
>
> == Contingency Plan ==
>
> This change depends on whether upstream merges this new default
> behavior. If upstream does not merged the feature in time, this Change
> will be postponed until the next Fedora version to avoid potential
> incompatibilities between configurations or commandline options.
>
> * Contingency mechanism: keep current behavior, try again with next
> Fedora version
> * Contingency deadline: beta freeze
> * Blocks release? No
>
>
> == Documentation ==
>
> == Release Notes ==
>
So I guess this means no remoting into ppc64 or s390x machines from
x86_64 or ppc64le machines without a configuration tweak?
No X11 forwarding, correct. Other protocols like VNC will continue to work.
I am honestly surprised that this is a use-case that arises frequently in
practice; I would expect ppc64 and especially s390x machines to be managed
via SSH or dedicated configuration management software such as Ansible or Salt.
Or do modern versions of X use consistent endianness regardless of
architecture?