Re: Authentication vulnerabilities in OpenBSD

[Solar Designer <solar () openwall com>]

On Wed, Dec 04, 2019 at 08:49:22PM +0000, Qualys Security Advisory wrote:
> 1. CVE-2019-19521: Authentication bypass

> This is the second piece of the puzzle: if an attacker specifies the
> username "-schallenge" (or "-schallenge:passwd" to force a passwd-style
> authentication), then the authentication is automatically successful and
> therefore bypassed.

Wow, this is the new -froot.

> 2. CVE-2019-19520: Local privilege escalation via xlock
> ==============================================================================
>
> On OpenBSD, /usr/X11R6/bin/xlock is installed by default and is
> set-group-ID "auth", not set-user-ID; the following check is therefore
> incomplete and should use issetugid() instead:
>
> ------------------------------------------------------------------------------
> 101 _X_HIDDEN void *
> 102 driOpenDriver(const char *driverName)
> 103 {
> ...
> 113    if (geteuid() == getuid()) {
> 114       /* don't allow setuid apps to use LIBGL_DRIVERS_PATH */
> 115       libPaths = getenv("LIBGL_DRIVERS_PATH");
> ------------------------------------------------------------------------------
>
> A local attacker can exploit this vulnerability and dlopen() their own
> driver to obtain the privileges of the group "auth":

I think this library issue isn't OpenBSD-specific.  A quick Google web
search for LIBGL_DRIVERS_PATH finds that Mesa appears to have the same
issue, and it also finds that we should also search for GBM_DRIVERS_PATH
(apparently, for older Mesa) and maybe EGL_DRIVERS_PATH and EGL_DRIVER,
and LIBVA_DRIVERS_PATH and LIBVA_DRIVER_NAME.  There are probably more.

Related discussion for X.Org, which ends with Alan Coopersmith saying:

"Yeah, I really would rather not have a setuid-root program dlopen and execute
code from a user supplied path.  Can we have something in there to prevent
disasters, such as issetugid() or secure_getenv()?"

[PATCH xserver] Search for DRI drivers at LIBGL_DRIVERS_PATH environment variable.
https://lists.x.org/archives/xorg-devel/2016-April/049336.html

It sounds like the patch adding the dangerous getenv() didn't get in,
but I didn't verify that.

Alexander