This means, that only sle15/GA and TW/factory is affected by that issue.

as these do not have the X server is not setuid root it is less important.

Not sure. IIRC -modulepath can also be used by a standard user in certain cases (depending on the specified path), which is exploited here, isn't it?

"ignore,/tmp/xorg-modules"

is seen as a valid relative path to the default path /usr/lib64/xorg/modules (valid to be specified by a standard user), but apparently modules then will be searched in /tmp/xorg-modules instead (not sure why though).

(In reply to Stefan Dirsch from comment #3)
> Not sure. IIRC -modulepath can also be used by a standard user in certain
> cases (depending on the specified path), which is exploited here, isn't it?

Ok. It's more or less impossible to get an Xserver started as a standard user without systemd-logind, since it needs permissions for /dev/tty*, /dev/dri/card*, etc.

Nevertheless I can reproduce the issue with

  "ignore,/tmp/xorg-modules"

when Xorg binary is suid. It really is loading the modules below /tmp/xorg-modules. And this doesn't happen when specifying.

  "/tmp/xorg-modules"

instead.

Ok. My understanding is that you can pass a list of directories seperated by "," with this option. So I guess it will be the same fix as in
bsc#1111697.

Created attachment 786528 [details]
0001-Disable-modulepath-when-running-with-elevated-privil.patch

Please let me know, whether I should our xserver for sle15 and TW with that patch or wait for an official one. Or just do nothing, since we no longer set suid bit since sle12 ...

[....] whether I should patch  our xserver [...]

The attack scenario is a setuid root X server, yes.

I would include the fix now, as there is the likely possibility people add the setuid root on their local instances for some reasons.

(In reply to Marcus Meissner from comment #10)
> The attack scenario is a setuid root X server, yes.
> 
> I would include the fix now, as there is the likely possibility people add
> the setuid root on their local instances for some reasons.

Ok. Since it isn't urgent I'm going to wait until we see the official patch in xserver git and will do the update then - for sle15 and TW at the same time. ;-)

public now

X.Org security advisory: October 25, 2018

Privilege escalation and file overwrite in X.Org X server 1.19 and later
========================================================================

Incorrect command-line parameter validation in the Xorg X server can
lead to privilege elevation and/or arbitrary files overwrite, when the
X server is running with elevated privileges (ie when Xorg is
installed with the setuid bit set and started by a non-root user).

The -modulepath argument can be used to specify an insecure path to
modules that are going to be loaded in the X server, allowing to
execute unprivileged code in the privileged process.

The -logfile argument can be used to overwrite arbitrary files in the
file system, due to incorrect checks in the parsing of the option.

This issue has been assigned CVE-2018-14665

Background
==========

The commit
https://gitlab.freedesktop.org/xorg/xserver/commit/032b1d79b7 which
first appeared in xorg-server 1.19.0 introduced a regression in the
security checks performed for potentially dangerous options, enabling
the vulnerabilities listed above.

Overwriting /etc/shadow with -logfile can also lead to privilege
elevation since it's possible to control some part of the written log
file, for example using the -fp option to set the font search path
(which is logged) and thus inject a line that will be considered as
valid by some systems.

Patches
=======

A patch for the issue was added to the xserver repository on
October 25, 2018.

https://gitlab.freedesktop.org/xorg/xserver/commit/50c0cf885a6e91c0ea71fb49fa8f1b7c86fe330e

Workaround
==========

If a patched version of the X server is not available, X.Org
recommends to remove the setuid bit (ie chmod 755) of the installed
Xorg binary.  Note that this can cause issues if people are starting
the X window system using the 'startx', 'xinit' commands or variations
thereof.

X.Org recommends the use of a display manager to start X sessions,
which does not require Xorg to be installed setuid.

Thanks
======

X.Org thanks Narendra Shinde who discovered and reported the issue,
and the Red Hat Product Security Team who helped understand all
impacts.

-- 
Matthieu Herrb

Is the plan for TW to patch or rev the package to 1.20.3? http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.20.3.tar.bz2.

Now I'm wondering to see a person without @suse.com mail address in a security bug!?! Anyway, for TW/factory we'll make a Xserver version update. Sle15/Leap15 will receive patch.

All security bugs become public accessible after embargo ends.

TW/factory done
sle15 done
sle12-sp4 (with updated xorg-server 1.19.6) done

Reassigning back to sec team.

This is an autogenerated message for OBS integration:
This bug (1112020) was mentioned in
https://build.opensuse.org/request/show/645321 Factory / xorg-x11-server
https://build.opensuse.org/request/show/645323 15.0 / xorg-x11-server

SUSE-SU-2018:3680-1: An update that fixes one vulnerability is now available.

Category: security (moderate)
Bug References: 1112020
CVE References: CVE-2018-14665
Sources used:
SUSE Linux Enterprise Workstation Extension 15 (src):    xorg-x11-server-1.19.6-8.3.2
SUSE Linux Enterprise Module for Open Buildservice Development Tools 15 (src):    xorg-x11-server-1.19.6-8.3.2
SUSE Linux Enterprise Module for Development Tools 15 (src):    xorg-x11-server-1.19.6-8.3.2
SUSE Linux Enterprise Module for Basesystem 15 (src):    xorg-x11-server-1.19.6-8.3.2

shown as done here

openSUSE-SU-2018:3800-1: An update that fixes one vulnerability is now available.

Category: security (moderate)
Bug References: 1112020
CVE References: CVE-2018-14665
Sources used:
openSUSE Leap 15.0 (src):    xorg-x11-server-1.19.6-lp150.7.3.1

This is an autogenerated message for OBS integration:
This bug (1112020) was mentioned in
https://build.opensuse.org/request/show/651109 Factory / xorg-x11-server