Authentication Vulnerabilities in OpenBSD, NetBSD 9.0 RC1 is available, Running FreeNAS on a DigitalOcean droplet, NomadBSD 1.3 is here, at e2k19 nobody can hear you scream, and more.
Headlines
Authentication vulnerabilities in OpenBSD (https://www.openwall.com/lists/oss-security/2019/12/04/5)
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.
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 loginpasswd(8).
skey Send a challenge and request a response, checking it with S/Key (tm) authentication. See loginskey(8).
yubikey Authenticate using a Yubico YubiKey token. See loginyubikey(8).
For any given style, the program /usr/libexec/auth/loginstyle 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.
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
Case study: ldapd
Case study: radiusd
Case study: sshd
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.
First release candidate for NetBSD 9.0 available! (https://blog.netbsd.org/tnf/entry/first_release_candidate_for_netbsd)
Since the start of the release process four months ago a lot of improvements went into the branch - more than 500 pullups were processed!
This includes usbnet (a common framework for usb ethernet drivers), aarch64 stability enhancements and lots of new hardware support, installer/sysinst fixes and changes to the NVMM (hardware virtualization) interface.
We hope this will lead to the best NetBSD release ever (only to be topped by NetBSD 10 next year).
Here are a few highlights of the new release:
Support for Arm AArch64 (64-bit Armv8-A) machines, including "Arm ServerReady"
compliant machines (SBBR+SBSA)
Enhanced hardware support for Armv7-A
Updated GPU drivers (e.g. support for Intel Kabylake)
Enhanced virtualization support
Support for hardware-accelerated virtualization (NVMM)
Support for Performance Monitoring Counters
Support for Kernel ASLR
Support several kernel sanitizers (KLEAK, KASAN, KUBSAN)
Support for userland sanitizers
Audit of the network stack
Many improvements in NPF
Updated ZFS
Reworked error handling and NCQ support in the SATA subsystem
Support a common framework for USB Ethernet drivers (usbnet)
More information on the RC can be found on the NetBSD 9 release page (https://www.netbsd.org/releases/formal-9/NetBSD-9.0.html)
News Roundup
Running FreeNAS on a Digitalocean droplet (https://www.shlomimarco.com/post/running-freenas-on-a-digitalocean-droplet)
ZFS is awesome. FreeBSD even more so. FreeNAS is the battle-tested, enterprise-ready-yet-home-user-friendly s