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? Or do modern versions of X use consistent endianness regardless of architecture? -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
