Vulnerabilities in OpenBSD allowing privilege escalation and authentication bypass in smtpd, ldapd and radiusd

Qualys Company has revealed four vulnerabilities in OpenBSD, one of which allows you to connect remotely without authentication to some network services, and the other three to increase their privileges in the system. The Qualys report noted the rapid response of the OpenBSD developers - all problems were eliminated в OpenBSD 6.5 и OpenBSD 6.6 within 40 hours after the private notice.

The remotely exploitable vulnerability is caused by an error in arranging the call to the authentication handler in the libc library, which calls
/usr/libexec/auth/login_style program passing arguments on the command line. Including when calling login_style using the optional parameter "-s service", passing the name of the protocol is allowed. If a "-" character is used at the beginning of the username, this name will be treated as an option when login_style is run. Accordingly, if you specify “-schallenge” or “-schallenge: passwd” as the username during authentication, then login_style will perceive the request as a request to use the handler S/Key.

The problem is that the S/Key protocol in login_style is supported only formally, but is actually ignored with the output of a sign of successful authentication. Thus, an attacker can pose as the "-schallenge" user and bypass authentication and gain access without specifying a password or keys. All network services that use regular libc calls for authentication are potentially affected by the problem. For example, the ability to bypass authentication is confirmed in smtpd (AUTH PLAIN), ldapd and radiusd.

The vulnerability does not manifest itself in sshd, since it has additional protection with checking the user's presence in the system. However, sshd can be used to test if a system is susceptible to a vulnerability - when accessing the username "-sresponse:passwd", the connection hangs, since sshd waits for login_passwd to return the parameters of the call (challenge), and login_passwd waits for the transfer of missing parameters (name "- sresponse" is taken as an option). A potential local attacker could try to bypass authentication in the su utility, but passing the name "-sresponse" causes the process to crash due to the return of a null pointer when executing the getpwnam_r("-schallenge", ...) function.

Other vulnerabilities:

  • CVE-2019-19520 - Local privilege escalation via manipulating the xlock utility that comes with the sgid flag that changes the group to "auth". In the xlock code, redefinition of library paths is prohibited only when the user ID (setuid) is changed, which allows the attacker to change the environment variable "LIBGL_DRIVERS_PATH" and organize the loading of his shared library, the code of which will be executed after privilege escalation to the "auth" group.
  • CVE-2019-19522 - Allows a local user in the "auth" group to run code as root when S/Key or YubiKey authentication is enabled in the system (not enabled by default). Membership in the "auth" group, which can be accessed by exploiting the above xlock vulnerability, allows files to be written to the /etc/skey and /var/db/yubikey directories. For example, an attacker could add a new /etc/skey/root file to generate one-time keys for root authentication via S/Key.
  • CVE-2019-19519 - Possibility to increase resource limits through manipulations with the su utility. When specifying the "-L" option, which implies a cyclic repetition of authentication attempts in case of failure, the user class is set only once and is not reset on subsequent attempts. An attacker can execute “su -l -L” on the first attempt to enter someone else's login with a different account class, but on the second attempt to successfully authenticate under himself. In this situation, the user will be set limits corresponding to the user class specified on the first attempt (for example, the maximum number of processes or the memory size for a process). The method only works for borrowing limits from non-privileged users, since the root user needs to be in the wheel group).

Additionally, it can be noted Implementation of in OpenBSD a new method for checking the validity of system calls, further complicating the exploitation of vulnerabilities. The method allows system calls to be executed only if they are accessed from previously registered memory areas. To mark areas of memory proposed new system call msyscall().

Source: opennet.ru