ssh -2 and hostbasedauth

[Dan Astoorian]

On Sat, 17 Nov 2001 19:28:23 EST, Gert Doering writes:
> 
> I can see the argument about disclosing information (which not-to-do is
> one of the mantras of security), but I'm not really sure why this would
> give a hacker advantage, unless he has already access to the box, like
> write-access-over-NFS-on-$HOME or so.

Verifying which hosts are in a user's .shosts file might give a
potential attacker hints about which host(s) to concentrate efforts on.
Suppose I'm targeting your account specifically, and I'm in a position
to sniff traffic and spoof at the IP level (which, unlike NFS-on-$HOME,
is an attack vector SSH is specifically designed to be a countermeasure
against).  I might watch a couple of thousand different hosts making SSH
connections to "greenie.muc.de," a few of which might be for
"gert at greenie.muc.de," but most of which (let's say) are from other
users of the machine.  If I can find out via IP spoofing that your
account trusts user "gert" (or "gdoering," or any other username I might
be able to predict) on one of those hosts in particular--say,
"gert at example.org", I might spend more time trying to get root on
example.org, or to find some other way to acquire its host key.

(In the specific case of .shosts, I'm not certain how much information
can already be deduced at the protocol level: if it's the case that the
server doesn't even issue the host key challenge unless an shosts.equiv
or .shosts check has succeeded--and I admit I haven't yet investigated
whether this is or should be the case--then the client would already
have this information with or without the debug message.)

-- 
Dan Astoorian               People shouldn't think that it's better to have
Sysadmin, CSLab             loved and lost than never loved at all.  It's
djast at cs.toronto.edu        not, it's better to have loved and won.  All
www.cs.toronto.edu/~djast/  the other options really suck.    --Dan Redican