On Wed, Jul 20, 2016 at 09:02:57PM -0600, Selphie Keller wrote:> I wonder if could be useful to set the fall back account to something user > defined to avoid suggesting people add passwords to root, though I do like > root since the account is always there,Since committing that diff I've heard of people running in production with no root password (ie *LK*, !! or similar). It's about the same amount of code to search for the first account with a valid salt, which would avoid this problem in the case where the root account doesn't have a real password. djm: what do you think? diff --git a/openbsd-compat/xcrypt.c b/openbsd-compat/xcrypt.c index 8913bb8..5385243 100644 --- a/openbsd-compat/xcrypt.c +++ b/openbsd-compat/xcrypt.c @@ -78,14 +78,18 @@ pick_salt(void) if (salt[0] != '\0') return salt; strlcpy(salt, "xx", sizeof(salt)); - if ((pw = getpwuid(0)) == NULL) - return salt; - passwd = shadow_pw(pw); - if (passwd[0] != '$' || (p = strrchr(passwd + 1, '$')) == NULL) - return salt; /* no $, DES */ - typelen = p - passwd + 1; - strlcpy(salt, passwd, MIN(typelen, sizeof(salt))); - explicit_bzero(passwd, strlen(passwd)); + setpwent(); + while ((pw = getpwent()) != NULL) { + passwd = shadow_pw(pw); + if (passwd[0] == '$' && (p = strrchr(passwd+1, '$')) != NULL) { + typelen = p - passwd + 1; + strlcpy(salt, passwd, MIN(typelen, sizeof(salt))); + explicit_bzero(passwd, strlen(passwd)); + goto out; + } + } + out: + endpwent(); return salt; } -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
yeah I like this idea, fixes the issue with blowfish hashes and non root passwords, maybe random delay as the final fall back if no salts/passwords are found. Seems rare, but I do have one box that I use ssh keys on and none of the accounts have a hash set, but I also don't have password auth enabled. On 20 July 2016 at 21:18, Darren Tucker <dtucker at zip.com.au> wrote:> On Wed, Jul 20, 2016 at 09:02:57PM -0600, Selphie Keller wrote: > > I wonder if could be useful to set the fall back account to something > user > > defined to avoid suggesting people add passwords to root, though I do > like > > root since the account is always there, > > Since committing that diff I've heard of people running in production > with no root password (ie *LK*, !! or similar). > > It's about the same amount of code to search for the first account with > a valid salt, which would avoid this problem in the case where the root > account doesn't have a real password. > > djm: what do you think? > > diff --git a/openbsd-compat/xcrypt.c b/openbsd-compat/xcrypt.c > index 8913bb8..5385243 100644 > --- a/openbsd-compat/xcrypt.c > +++ b/openbsd-compat/xcrypt.c > @@ -78,14 +78,18 @@ pick_salt(void) > if (salt[0] != '\0') > return salt; > strlcpy(salt, "xx", sizeof(salt)); > - if ((pw = getpwuid(0)) == NULL) > - return salt; > - passwd = shadow_pw(pw); > - if (passwd[0] != '$' || (p = strrchr(passwd + 1, '$')) == NULL) > - return salt; /* no $, DES */ > - typelen = p - passwd + 1; > - strlcpy(salt, passwd, MIN(typelen, sizeof(salt))); > - explicit_bzero(passwd, strlen(passwd)); > + setpwent(); > + while ((pw = getpwent()) != NULL) { > + passwd = shadow_pw(pw); > + if (passwd[0] == '$' && (p = strrchr(passwd+1, '$')) !> NULL) { > + typelen = p - passwd + 1; > + strlcpy(salt, passwd, MIN(typelen, sizeof(salt))); > + explicit_bzero(passwd, strlen(passwd)); > + goto out; > + } > + } > + out: > + endpwent(); > return salt; > } > > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. >
On Thu, Jul 21, 2016 at 1:34 PM, Selphie Keller <selphie.keller at gmail.com> wrote:> yeah I like this idea, fixes the issue with blowfish hashes and non root > passwords, maybe random delay as the final fall back if no salts/passwords > are found.Well if there are no accounts with a valid salt then there's also no valid account to compare the timing of invalid accounts against. Worst case that'd be DES crypt vs empty password and I'm not sure if you'd be able to pick that out of the background crypto.> Seems rare, but I do have one box that I use ssh keys on and none > of the accounts have a hash set, but I also don't have password auth > enabled.IMO random delays are overrated for mitigating timing attacks; you can look for inconsistent behaviour as the indicator of whatever you're looking for. -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
Quoting Darren Tucker <dtucker at zip.com.au>:> Since committing that diff I've heard of people running in production > with no root password (ie *LK*, !! or similar). > > It's about the same amount of code to search for the first account with > a valid salt, which would avoid this problem in the case where the root > account doesn't have a real password. > > djm: what do you think?Since OpenSSH already makes use of an unprivileged user for privsep, why not take the next step of setting a (long) random password for it using the system's normal shadow password routines? If one is concerned about an accidentally "successful" login, you could perturb the supplied passphrase prior to passing it down to the authentication library to ensure a successful entry is impossible. Alternately, a second "dummy" account that's not used at all by the system which is a chroot jail with nothing in it with a random password? This way no bizarre system assumptions need be made, and it accommodates the wide range of "policy" preferences for the bulk of the userbase. =M=
On Thu, Jul 21, 2016 at 2:00 PM, Morham Anthelleron <opensshdev at r.paypc.com> wrote: [...]> Since OpenSSH already makes use of an unprivileged user for privsep, why not > take the next step of setting a (long) random password for it using the > system's normal shadow password routines?Assuming you mean putpwent(): that requires an encrypted string to put in pw_passwd putting us right back where we started.> If one is concerned about an accidentally "successful" login, you could > perturb the supplied passphrase prior to passing it down to the authentication > library to ensure a successful entry is impossible. > > Alternately, a second "dummy" account that's not used at all by the system > which is a chroot jail with nothing in it with a random password?If we could reliably come up with the encrypted string to put in that dummy account we wouldn't need the dummy account. Actually setting a password is quite system dependent. exec'ing /bin/passwd in most cases needs a controlling terminal although some have flags for reading form stdin. Using pam_chauthtok() would require making assumptions about what the prompts were. Some systems enforce complexity (as opposed to entropy) requirements. And then you'd have an account with a password that you're not quite sure where it came from. -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.