Re: F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux