On Wed, Dec 21, 2022 at 09:08:54PM -0500, 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? We don't have ppc64 builds anymore and I don't know the last release we had that was ppc64, but it was a long time ago now. All current POWER systems are ppc64le. And everything else we have as primary or alternative architectures is little endian, except s390x. I do view this as a risk for s390x because of all the architectures we build for, this one is the most difficult to use graphically. Exporting your display is still the convenient method for this platform. Given that this change proposal affects default behavior, I don't see a problem with it. s390x users can drop the configuration change in xorg.conf.d to regain the functionality. If that can be conditionally enabled for s390x at package build time, that might make things easier (but wouldn't you need to make the change on both the s390x host and your non-s390x workstation?). > Or do modern versions of X use consistent endianness regardless of architecture? Thanks, -- David Cantrell <dcantrell@xxxxxxxxxx> Red Hat, Inc. | Boston, MA | EST5EDT _______________________________________________ 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
