[Bug 2909] New: sshd segfaults on non-existent users when there is an NIS ngetgroup included in /etc/passwd

[bugzilla-daemon at bugzilla.mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=2909

            Bug ID: 2909
           Summary: sshd segfaults on non-existent users when there is an
                    NIS ngetgroup included in /etc/passwd
           Product: Portable OpenSSH
           Version: 7.7p1
          Hardware: ix86
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: todd at xymmetrix.com

Created attachment 3181
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3181&action=edit
segfault test program

We might have a bit of an odd/old configuration, but it works
otherwise.

We get lots and lots of these. This is the only machine whose sshd is
exposed to the internet:

Sep 25 09:42:53 pluto kernel: sshd[1871]: segfault at 0 ip 005023ac sp
7f899810 error 4 in sshd[49b000+6d000]

Normal users here can log in fine, so I figured it was just trash the
password-searchers were throwing at sshd. I finally took some time to
dig in to it. It turns out that trying to ssh in as an invalid user
(ssh foo at pluto) causes sshd to segfault as soon as I enter the
password.

Once I could duplicate it at will it was pretty easy to chase down. The
pick_salt() function iterates through users with getpwent() looking for
a salt it can use. Our setup doesn't use shadow passwords, so it
doesn't find what it's looking for. When it gets to the end of the
password file, the last line is "+ at users" to add in our NIS user
netgroup.

shadow_pw() can't find a password in that line, so it returns NULL,
which pointer is them immediately dereferenced.

I extracted the relevant code into a standalone program that
demonstrates the problem, attached. (I used entire functions; I didn't
pare it down to absolute bare minimum--but there are only three
functions.) When I run it on this system, it produces the following
output:

pw = 77efacc0
pw_name = '+ at users'
  passwd = '(null)'
Segmentation fault



This small change takes care of it:

--- openssh-7.8p1/openbsd-compat/xcrypt.c.orig  2018-08-23
01:41:42.000000000 -0400
+++ openssh-7.8p1/openbsd-compat/xcrypt.c       2018-09-25
10:11:11.639816915 -0400
@@ -83,7 +83,7 @@
        setpwent();
        while ((pw = getpwent()) != NULL) {
                passwd = shadow_pw(pw);
-               if (passwd[0] == '$' && (p = strrchr(passwd+1, '$')) !=
NULL) {
+               if (passwd && passwd[0] == '$' && (p =
strrchr(passwd+1, '$')) != NULL) {
                        typelen = p - passwd + 1;
                        strlcpy(salt, passwd, MIN(typelen,
sizeof(salt)));
                        explicit_bzero(passwd, strlen(passwd));



We compile --prefix=/usr --without-shadow.

We're running 7.8p1 now. This problem predates 7.8, though; I'm not
sure how far back it goes.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.