On 12/21/22 21:08, Neal Gompa wrote: > On Wed, Dec 21, 2022 at 4:49 PM Ben Cotton <bcotton@xxxxxxxxxx> 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@xxxxxxxxxx >> >> >> == 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? Sadly no. -- Sincerely, Demi Marie Obenour (she/her/hers) _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
