1. 67
  1.  

  2. 20

    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.

    1. 2

      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.

      1. 5

        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.

      2. 1

        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 :)

        1. 1

          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.

          1. 1

            This is OpenBSD in general.

        2. 7

          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:

          ssh -v -F /dev/null -o PreferredAuthentications=keyboard-interactive \
            -o KbdInteractiveDevices=bsdauth -l -sresponse:passwd
          

          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.

          Awesome bug report and quick fix !

          1. 5

            OpenBSD only produces syspatches for the 2 most recent releases (6.5 and 6.6 currently). Upgrade from 6.4 to 6.6. :)

          2. 7

            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…

            1. 2

              I remember this on AIX.

            2. 5

              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

              1. 2

                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).

                1. 3

                  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 :)

                  1. 3

                    Eh, shared libraries have issues that exe’s don’t, for example unterminated strings. It’s a tradeoff either way.