backdoor by authorized_keys2 leftovers

[Dan Kaminsky]

Sent from my iPhone

On May 12, 2011, at 6:47 PM, Iain Morgan <imorgan at nas.nasa.gov> wrote:

> On Thu, May 12, 2011 at 14:14:02 -0500, Dan Kaminsky wrote:
>> On Thu, May 12, 2011 at 11:49 AM, Markus Friedl <mfriedl at gmail.com> wrote:
>> 
>>> looks like we've been waiting too long :)
>>> 
>>> http://www.openssh.com/txt/release-3.0
>>> 
>>> 2) The files
>>> /etc/ssh_known_hosts2
>>> ~/.ssh/known_hosts2
>>> ~/.ssh/authorized_keys2
>>> are now obsolete, you can use
>>> /etc/ssh_known_hosts
>>> ~/.ssh/known_hosts
>>> ~/.ssh/authorized_keys
>>> For backward compatibility ~/.ssh/authorized_keys2 will still used for
>>> authentication and hostkeys are still read from the known_hosts2.
>>> However, those deprecated files are considered 'readonly'. Future
>>> releases are likely not to read these files.
>>> 
>> 
>> In no uncertain terms, removal of authorized_keys2 support will cause
>> outages, up to and including requiring physical access for administrators to
>> resolve.  Documentation is not an excuse to make this change.
>> 
>> It's completely reasonable, desirable even, to allow a new configuration
>> option to explicitly define the set of files that can contain authorized
>> keys.  It'd even be convenient to have an AuthorizationCommand option, that
>> sent properly escaped strings to a command for external testing and
>> validation.
>> 
> 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.

A vaguely nice security change cannot justify extensive notification and lockout risk.  And we're not really in the position to collect data saying the risk is small enough.


> -- 
> Iain morgan