Bug 1112020 - VUL-0: xorg-x11-server: code injection via -modulepath
VUL-0: xorg-x11-server: code injection via -modulepath
Status: RESOLVED FIXED
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
unspecified
Other Other
: P3 - Medium : Normal
: ---
Assigned To: Security Team bot
Security Team bot
https://smash.suse.de/issue/216670/
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-10-16 13:38 UTC by Marcus Meissner
Modified: 2018-11-22 14:05 UTC (History)
4 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
0001-Disable-modulepath-when-running-with-elevated-privil.patch (1.19 KB, patch)
2018-10-19 10:37 UTC, Stefan Dirsch
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Comment 1 Stefan Dirsch 2018-10-16 14:07:50 UTC
This means, that only sle15/GA and TW/factory is affected by that issue.
Comment 2 Marcus Meissner 2018-10-16 14:53:16 UTC
as these do not have the X server is not setuid root it is less important.
Comment 3 Stefan Dirsch 2018-10-16 20:26:17 UTC
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?
Comment 4 Stefan Dirsch 2018-10-16 20:31:52 UTC
"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).
Comment 5 Stefan Dirsch 2018-10-19 10:11:59 UTC
(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.
Comment 6 Stefan Dirsch 2018-10-19 10:36:22 UTC
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.
Comment 7 Stefan Dirsch 2018-10-19 10:37:20 UTC
Created attachment 786528 [details]
0001-Disable-modulepath-when-running-with-elevated-privil.patch
Comment 8 Stefan Dirsch 2018-10-19 10:39:49 UTC
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 ...
Comment 9 Stefan Dirsch 2018-10-19 10:40:32 UTC
[....] whether I should patch  our xserver [...]
Comment 10 Marcus Meissner 2018-10-19 11:38:55 UTC
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.
Comment 11 Stefan Dirsch 2018-10-19 12:33:54 UTC
(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. ;-)
Comment 15 Marcus Meissner 2018-10-25 14:41:03 UTC
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
Comment 16 Sean Lewis 2018-10-26 15:04:45 UTC
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.
Comment 17 Stefan Dirsch 2018-10-27 08:25:27 UTC
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.
Comment 18 Marcus Meissner 2018-10-29 15:23:00 UTC
All security bugs become public accessible after embargo ends.
Comment 19 Stefan Dirsch 2018-10-29 16:03:46 UTC
TW/factory done
sle15 done
sle12-sp4 (with updated xorg-server 1.19.6) done

Reassigning back to sec team.
Comment 20 Swamp Workflow Management 2018-10-29 16:30:07 UTC
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
Comment 23 Swamp Workflow Management 2018-11-08 20:09:35 UTC
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
Comment 25 Andreas Stieger 2018-11-16 17:49:32 UTC
shown as done here
Comment 26 Swamp Workflow Management 2018-11-16 23:12:48 UTC
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
Comment 28 Swamp Workflow Management 2018-11-22 14:00:06 UTC
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