TL;DR didn’t sanitize usernames which could contain “-“ making them parse as options to the authentication program. Exploiting this, username “-schallenge:passwd” allowed silent auth bypass because the passwd backend doesn’t require a challenge.
It’s a modern marvel that people end up using web frameworks with automatic user data parsing and escaping for their websites, because if not so many places would have these kind of “game over” scenarios.
Is this specific to OpenWall users or is it applicable to OpenBSD in general?
From title it looks like an authentication vulnerability in the OpenBSD core os.
The above command will hang if the host is vulnerable. After running syspatch (no reboot), the command fails with the following error:
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: No more authentication methods to try.
-sresponse:passwd@bsd66.domain.tld: Permission denied (publickey,password,keyboard-interactive).
I have a 6.4 host that is still vulnerable after running syspatch though.
Similar in spirit to the old Solaris telnet vulnerability circa 2007. If you specified a username via the -l option and the username were in the form of -froot, the -froot would be passed as a flag to the login command and you’d get in pretty trivially.
IIRC it actually predated Solaris. Might even go back to BSD…
Beautiful find. Simple and clean exploitation, I’d use this one as a teaching example for this type of bug class (auth bypass due to unsanitized user input).
So much for bsdauth being better than PAM. At least PAM is based on shared libraries instead of executables — no command line args parsing in the plugin API :)
TL;DR didn’t sanitize usernames which could contain “-“ making them parse as options to the authentication program. Exploiting this, username “-schallenge:passwd” allowed silent auth bypass because the passwd backend doesn’t require a challenge.
Awesome find, great turnaround from Theo.
Yikes.
It’s a modern marvel that people end up using web frameworks with automatic user data parsing and escaping for their websites, because if not so many places would have these kind of “game over” scenarios.
Usernames in web applications are not easy, nor is there wide awareness of the problems or deployment of solutions.
If you’re interested in learning more, I’ve gone on about this at some length.
If memory serves right, there was an old login bug (circa ’99) that was the same sort of thing:
http://seclab.cs.ucdavis.edu/projects/testing/vulner/18.html
Edit: https://lobste.rs/s/bufolq/authentication_vulnerabilities#c_jt9ckw
Too slow I guess :)
Is this specific to OpenWall users or is it applicable to OpenBSD in general?
From title it looks like an authentication vulnerability in the OpenBSD core os.
This is OpenBSD in general.
Most importantly, running
syspatch(8)will fix the issue on openbsd 6.6. (patch 010_libcauth).As specified in the article, the vulnerability can be tested using the following command:
The above command will hang if the host is vulnerable. After running syspatch (no reboot), the command fails with the following error:
I have a 6.4 host that is still vulnerable after running syspatch though.
Awesome bug report and quick fix !
OpenBSD only produces syspatches for the 2 most recent releases (6.5 and 6.6 currently). Upgrade from 6.4 to 6.6. :)
Similar in spirit to the old Solaris telnet vulnerability circa 2007. If you specified a username via the
-loption and the username were in the form of-froot, the-frootwould be passed as a flag to thelogincommand and you’d get in pretty trivially.IIRC it actually predated Solaris. Might even go back to BSD…
I remember this on AIX.
Looks like this issue might have been there for quite some time.
Much of the patch: https://ftp.openbsd.org/pub/OpenBSD/patches/6.6/common/010_libcauth.patch.sig
Is patching code from 18-19 years ago:
https://github.com/openbsd/src/blame/df69c215c7c66baf660f3f65414fd34796c96152/lib/libc/gen/auth_subr.c#L307
Beautiful find. Simple and clean exploitation, I’d use this one as a teaching example for this type of bug class (auth bypass due to unsanitized user input).
So much for bsdauth being better than PAM. At least PAM is based on shared libraries instead of executables — no command line args parsing in the plugin API :)
Eh, shared libraries have issues that exe’s don’t, for example unterminated strings. It’s a tradeoff either way.