backdoor by authorized_keys2 leftovers

[Philip Hands]

On Thu, 12 May 2011 21:49:13 -0400, Dan Kaminsky <dan at doxpara.com> wrote:
...
> > Provided that sysadmins are aware of the change ahead of time, proactive
> > measures can easily be taken. On a per-system basis, it's obviously a
> > simple matter to find and rename such deprecated files. However, we can
> > expect that some will be caught off guard.
> > 
> > In hindsight, what probably should have been done is have sshd return a
> > warning to the client about the deprecated file after successful login.
> > And, for good measure, an appropriate message should be logged on the
> > server, if that's not already the case.
> > 
> > Given that support for authorized_keys2 hasn't been documented for a
> > number of years, I have to wonder just how widespread its use is.
> > 
> 
> Doesn't matter. A failure here locks the admin out of the server,
> requiring up to and including physical recovery.

How about if for the first release:

  if AuthorizedKeysFile is set, then that's fine, we're not defaulting to
  using the authorized_keys2 file anyway

  if it is not set, and authorized_keys2 file(s) exist on the system,
  put up a warning if it's an interactive login, log a warning, and
  pause for 20 seconds before then allowing the login.

That should get people's attention.

To be certain that you're going to alert the sysadmins, you'd want to
check for any authorized_keys2 anywhere, but that's a bit cumbersome.

Perhaps it would be OK to only do it when one were using the keys out of
an authorized_keys2, although there is some danger that only automated
logins would be affected, and the delay and logs would go unnoticed.

Perhaps one could set a flag when an authorized_keys2 file had been
found at some point during the lifetime of the sshd, and change the
behaviour for all subsequent logins.

Leave that behaviour in place for a release or two, then just drop the
default use of authorized_keys2.  If anyone then gets caught out,
they've really not been paying attention.

If the above seems like too much effort (which it probably is), just put
it in the release notes, and suggest that people who package ssh make
sure that the user is alerted to the change (if AuthorizedKeysFile is unset).

Anyone who upgrades ssh remotely without testing that they can still log
in before they log out, is a dimwit.  That said, I've been that dimwit ;-)

Cheers, Phil.
-- 
|)|  Philip Hands [+44 (0)20 8530 9560]    http://www.hands.com/
|-|  HANDS.COM Ltd.                    http://www.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20110513/477bb6d4/attachment-0001.bin>