Authentication vulnerabilities in OpenBSD
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). ... yubikeyAuthenticate 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 shoul
BeeGFS Privilege Escalation (CVE-2019-15897)
BeeGFS Privilege Escalation (CVE-2019-15897) * Software: BeeGFS * Affected Versions: All versions upto and including 7.1.3 * Vendor: ThinkparQ * CVE: CVE-2019-15897 * Severity: CVSS 9.6 (Critical) [CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H] * Author: John Fitzpatrick * Date: 2019-12-04 Description === BeeGFS is a "leading parallel cluster filesystem", used in many HPC environments. A vulnerability exists in a default installation of BeeGFS which allows users to perform operations which allow them to elevate their privileges and become root. This is due to a failure to properly authenticate a user when performing filesystem operations. BeeGFS deployments utilising the BeeGFS cloudformation template were also affected by this issue. Installations which are making use of connection-based authentication, using the connAuthFile option to specify a shared key, are not affected by this issue if the shared key is only readable by root. Without a connAuthFile configured any host able to communicate with the BeeGFS cluster can become part of the cluster and mount the BeeGFS filesystem. In order to resolve this issue BeeGFS users should configure connection-based authentication within their environment ensuring that the shared key is only readable by root. This will prevent non root users from exploiting this issue but will prevent non-root users from utilising utilities such as beegfs-ctl. Solution / Workaround = This vulnerability can be mitigated by making use of the connAuthFile configuration option. This option, whilst intended to restrict which hosts can communicate with BeeGFS, can also be leveraged to prevent non root users from gaining root as a result of this weakness. This is done by setting the path to a shared key within the BeeGFS configuration file on each node. An example of this is shown below: connAuthFile = /etc/beegfs/connauthfile The contents of the connAuthFile can be anything but must be the same on each host as this is a shared key. If this key is readable by non-root users then it will be ineffective in preventing the attacks described above (although hosts without access to the key from joining the cluster), the key must be configured readable only by root: $ ls -la /etc/beegfs/connauthfile -rw--- 1 root root 640 Aug 28 02:29 /etc/beegfs/connauthfile With the connAuthFile option configured BeeGFS will derive a 64 bit key from the file containing the secret and this value is used to authenticate the communication channels when they are initially established as well as any subsequent communication channels. When configured communications which have not first authenticated with this key are ignored and silently dropped by the BeeGFS cluster. This mitigation does prevents non-root users from using any BeeGFS utilities (beegfs-ctl, beegfs-check-servers, etc.). No specific fix has been provided by BeeGFS for this vulnerability, therefore updating versions of BeeGFS will (currently) not resolve this issue. The workaround described above is the official supported recommendation from BeeGFS. The BeeGFS cloudformation templates have been updated in order to make use of a shared key. Timeline 2019-08-23: Issue reported to ThinkparQ 2019-08-26: Acknowledgement from ThinkparQ 2019-09-05: Details of proposed remediation from ThinkparQ and proposed disclosure date 2019-11-17: HPCsec pre-advisory published 2019-11-19: Confirmation that cloudformation templates have been updated 2019-12-04: Advisory published = https://www.hpcsec.com/2019/12/04/cve-2019-15897/ =
