Date:        Mon, 1 Jul 2002 17:08:15 +0200 (CEST)
    From:        Jaromir Dolecek <jdolecek@netbsd.org>
    Message-ID:  <200207011508.g61F8Fi23838@s102-n054.tele2.cz>

  | P.S kre: according to section 2. Impact of the above mentioned document,
  |     every SSH with 'ChallengeResponseAuthentication on' was vulnerable.
  | Quote:
  | """
  | 	This bug can be exploited remotely if ChallengeResponseAuthentication
  | 	is enabled in sshd_config.  This option is enabled
  | 	by default on OpenBSD and other systems.
  | """

Yes, thanks for that.   And to  Seth Kurtzberg for saying much the
same thing.   But I knew that.

I was asking a more detailed question though.    I appreciate that
people don't want to say too much about how security bugs were fixed,
on the assumption that the bug will then be easier to find and exploit
on systems where the no-one is bothering to do any updates, or even
implement safety measures.

I have spent a little time going through the sources, and seeing what
changed, and to me it appears that whoever reported earlier (sorry, I
have forgotten who that was) that the problem was in the handling of
the response to a challenge was exactly correct.

That is, if a system sends no challenge, and hence gets no responses,
I would have thought that it would be pretty safe.   Of course, I may
have missed some other subtle change (or there may be something else in
there that I didn't notice - all the noise changes don't help - or
which though part of the problem, wasn't deemed necessary of a fix).

Of course, if ChallengeResponseAuthentication is disabled, there will be
no way the system will send a challenge, so doing that is a nice safety
measure.

But, even if enabled, why would the system, send a challenge if there are
no uses on the system using s/key (skeykeys is empty)?   And if no challenge
is ever sent, surely no response would ever be parsed?

So, wouldn't systems be safe enough (from external threats) if they simply
had no users using s/key?   And if that's true, then as very few systems
use s/key any more (ssh is a much better way of securing connections and
avoiding passwords being sent in the clear...) wouldn't the impact of this
problem have been much less than has been suggested it may have been?

Note: this isn't to suggest to anyone that they should be lax about
upgrading their system (even though my skeykeys file is empty, I have
certainly not just done nothing) - but in these kinds of areas, in general
accurate information (even if delayed a little) is much much better than
hand waving (wolf crying).

kre