(Announcing the Change proposal) |
m (Fix typo in flag) |
||
(9 intermediate revisions by 2 users not shown) | |||
Line 2: | Line 2: | ||
= X Server Prohibits Byte-swapped Clients = | = X Server Prohibits Byte-swapped Clients = | ||
== Summary == | == Summary == | ||
Line 18: | Line 16: | ||
== Current status == | == Current status == | ||
[[Category: | [[Category:ChangeAcceptedF38]] | ||
[[Category:SystemWideChange]] | [[Category:SystemWideChange]] | ||
Line 30: | Line 28: | ||
--> | --> | ||
* [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/PGAHMALQKN6TRNCGFAOE2M4A3GRIL4D7/ devel thread] | * [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/PGAHMALQKN6TRNCGFAOE2M4A3GRIL4D7/ devel thread] | ||
* FESCo issue: | * FESCo issue: [https://pagure.io/fesco/issue/2927 #2927] | ||
* Tracker bug: | * Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=2159489 #2159489] | ||
* Release notes tracker: | * Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/949 #949] | ||
== Detailed Description == | == Detailed Description == | ||
Line 39: | Line 37: | ||
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. | 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 | The use-case for clients with different endianess is very niche. The vast majority of users never run a remote client, let alone a remote client on a machine with a different endianess. Fedora only supports [https://fedoraproject.org/wiki/Architectures one Big Endian architecture (s390x)], so the only Fedora users affected by this change are those running remote applications on an s390x. | ||
Note: | 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 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 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. | * this is a change in the [https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1029 upstream default behavior] that Fedora will follow along with. This Change is primarily to increase the exposure of this new behavior. | ||
Line 56: | Line 54: | ||
== Scope == | == Scope == | ||
* Proposal owners: | * Proposal owners: | ||
# Merge [https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1029 upstream PR] | # Merge [https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1029 upstream PR] - ''complete'' | ||
# Backport patch to Fedora's `xorg-x11-server` and `xorg-x11-server-Xwayland` packages | # Backport patch to Fedora's `xorg-x11-server` and `xorg-x11-server-Xwayland` packages - ''complete'' | ||
* Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
# | # For systems running `/usr/bin/Xorg`, no further changes are needed. Users/system administrators can configure the new option in the `xorg.conf` `ServerFlags` section. | ||
# Wayland compositors that manage `/usr/bin/Xwayland` (all of them?) that want to (re-)enable support for byte-swapped clients need to provide a configuration option to users that appends the `+byteswappedclients` option to the `Xwayland` invocation. | |||
#* GNOME 44 mutter provides the gsettings `xwayland-allow-byte-swapped-clients` option, see [https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2785 this PR] | |||
* Release engineering: [https://pagure.io/releng/issues #Releng issue number] <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Release engineering: [https://pagure.io/releng/issues #Releng issue number] <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
Line 69: | Line 69: | ||
* Trademark approval: N/A (not needed for this Change) | * Trademark approval: N/A (not needed for this Change) | ||
* Alignment with Objectives: | * Alignment with Objectives: | ||
== Upgrade/compatibility impact == | == Upgrade/compatibility impact == | ||
Line 76: | Line 76: | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
For the | For the 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'''. Such clients will print an error message to stderr: `Prohibited client endianess, see the Xserver man page`. | ||
For Xorg, the following `xorg.conf.d` snippet will re-enable the old behavior: | |||
<pre> | <pre> | ||
Section "ServerFlags" | Section "ServerFlags" | ||
Option " | Option "AllowByteSwappedClients" "on" | ||
EndSection | EndSection | ||
</pre> | </pre> | ||
Wayland users (and thus Xwayland) need to employ compositor-specific configuration to pass the `+byteswappedclients` flag to Xwayland. At the time of writing, | Wayland users (and thus Xwayland) need to employ compositor-specific configuration to pass the `+byteswappedclients` flag to Xwayland. At the time of writing, Wayland compositors do not yet provide such a configuration. | ||
* [https://gitlab.gnome.org/GNOME/mutter/-/issues/2576 GNOME mutter upstream issue] | |||
* [https://invent.kde.org/plasma/kwin/-/issues/131 KDE kwin upstream issue] | |||
* [https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3558 wlroots upstream issue] | |||
== How To Test == | == How To Test == | ||
Line 126: | Line 131: | ||
For virtually all users, there is no change in behavior. | For virtually all users, there is no change in behavior. | ||
Users with | Users of Xorg with the server and client on two differently-byte-ordered machines must add the `xorg.conf.d` snippet shown above on affected systems. For users of a Wayland compositor and thus Xwayland, they need to pass the `+byteswappedclients` option to Xwayland. This is a configuration option that must be provided by the respective compositor. | ||
== Dependencies == | == Dependencies == | ||
Line 160: | Line 165: | ||
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze. | Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze. | ||
--> | --> | ||
X server implementations (e.g. Xorg and Xwayland) no longer accept connections from remote clients with a byte endianess different to that of the X server **by default**. This removes a large attack surface in the X server that can be exploited by malicious clients. Users that require this particular use-case can re-enable this feature with the `AllowByteSwappedClients` option (see the xorg.conf man page), or passing `+byteswappedclients` to the X server invocation (see the Xserver man page). | |||
This change does users that do not use X forwarding (with or without ssh). |
Latest revision as of 12:27, 19 May 2023
X Server Prohibits Byte-swapped Clients
Summary
X server implementations (e.g. Xorg and Xwayland) will (by default) no longer allow clients with different endianess to connect.
Owner
- Name: Peter Hutterer
- Email: peter.hutterer@redhat.com
Current status
- Targeted release: Fedora Linux 38
- Last updated: 2023-05-19
- devel thread
- FESCo issue: #2927
- Tracker bug: #2159489
- Release notes tracker: #949
Detailed Description
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. 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. The vast majority of users never run a remote client, let alone a remote client on a machine with a different endianess. Fedora only supports one Big Endian architecture (s390x), so the only Fedora users affected by this change are those running remote applications on an s390x.
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 of this new behavior.
Feedback
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 upstream PR - complete
- Backport patch to Fedora's
xorg-x11-server
andxorg-x11-server-Xwayland
packages - complete
- Other developers:
- For systems running
/usr/bin/Xorg
, no further changes are needed. Users/system administrators can configure the new option in thexorg.conf
ServerFlags
section. - Wayland compositors that manage
/usr/bin/Xwayland
(all of them?) that want to (re-)enable support for byte-swapped clients need to provide a configuration option to users that appends the+byteswappedclients
option to theXwayland
invocation.- GNOME 44 mutter provides the gsettings
xwayland-allow-byte-swapped-clients
option, see this PR
- GNOME 44 mutter provides the gsettings
- Release engineering: #Releng issue number
- 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 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. Such clients will print an error message to stderr: Prohibited client endianess, see the Xserver man page
.
For Xorg, the following xorg.conf.d
snippet will re-enable the old behavior:
Section "ServerFlags" Option "AllowByteSwappedClients" "on" EndSection
Wayland users (and thus Xwayland) need to employ compositor-specific configuration to pass the +byteswappedclients
flag to Xwayland. At the time of writing, Wayland compositors do 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 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 of Xorg with the server and client on two differently-byte-ordered machines must add the xorg.conf.d
snippet shown above on affected systems. For users of a Wayland compositor and thus Xwayland, they need to pass the +byteswappedclients
option to Xwayland. This is a configuration option that must be provided by the respective compositor.
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
N/A (not a System Wide Change)
Release Notes
X server implementations (e.g. Xorg and Xwayland) no longer accept connections from remote clients with a byte endianess different to that of the X server **by default**. This removes a large attack surface in the X server that can be exploited by malicious clients. Users that require this particular use-case can re-enable this feature with the AllowByteSwappedClients
option (see the xorg.conf man page), or passing +byteswappedclients
to the X server invocation (see the Xserver man page).
This change does users that do not use X forwarding (with or without ssh).