[19156] in bugtraq
Re: severe error in SSH session key recovery patch
daemon@ATHENA.MIT.EDU (Andrew Brown)
Mon Feb 12 17:41:45 2001
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Errors-To: owner-bugtraq@SECURITYFOCUS.COM
Message-Id: <20010211120739.A704@noc.untraceable.net>
Date: Sun, 11 Feb 2001 12:07:39 -0500
Reply-To: bugtraq@SECURITYFOCUS.COM
From: Andrew Brown <atatat@ATATDOT.NET>
X-To: Matt Power <mhpower@BOS.BINDVIEW.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <200102091938.OAA25451@theta.bos.bindview.com>; from
mhpower@BOS.BINDVIEW.COM on Fri, Feb 09, 2001 at 02:38:02PM -0500
> -- With the patch, the lifespan of the server key still does not go
> below one minute. As mentioned in CORE SDI's advisory, the number
> of server connections necessary to carry out the attack is
> normally very large but "the number of connections given is for
> the average case and specifics cases will fall below the
> average". This suggests that is not entirely out of the question
> for the attack to succeed within one minute. If that risk is not
> appropriate in one's environment, then other measures (which may
> include inetd/tcpserver but may also include desupporting use of
> SSH protocol 1.5) are needed.
1) {
2) static time_t last_kill_time = 0;
3) if (time(NULL) - last_kill_time > 60 && getppid() != 1)
4) {
5) last_kill_time = time(NULL);
6) kill(SIGALRM, getppid());
7) }
8) fatal("Bad result from rsa_private_decrypt");
9) }
actually...if we look at the lines that the patch adds, i think it's
pretty clear that the variable last_kill_time, declared at line 2 to
be static and initialized to 0, will always be 0 at line 3 (since it
can't get set to anything else from other code...it's static), which
means that the kill (and setting the actual of last_kill_time to
something other than 0) will almost always take place (now - 0 is
usually a lot more than 60), and the fact that it finally get set
doesn't mean anything to anyone, since the only process that recorded
that the signal was sent immediately exits at line 8.
unless i'm missing something, this turns the vulnerability from a
possible (but difficult) theft of a session key to very easy denial of
service attack. all i need to do is keep connecting and screwing up
and your main sshd will churn on and on making itself new server keys.
--
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org * "ah! i see you have the internet
twofsonet@graffiti.com (Andrew Brown) that goes *ping*!"
andrew@crossbar.com * "information is power -- share the wealth."
