Created attachment 3181 [details]
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@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 "+@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 = '+@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.