Re: ssh exploit?

[Christian Jaeger <christian.jaeger@sl.ethz.ch>]

At 9:43 Uhr -0600 30.11.2001, Dave Sherohman wrote:
> Heard a rumor on the local LUG mailing list this morning about a
> remote root exploit in sshd.  Nothing resembling details was
> presented, just a link to the openssh-unix-dev mailing list archive:
>
> http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=100696253318793&w=2
>
> Anybody know anything of substance about it?  Assuming it's real, are
> current debian versions affected?  (I assume so, but don't have the
> exploit code to test it.)

The reply to the message from the given url indicates that the 
exploit is using "the old bug in deattack.c".

A little research gave me:

<http://www.openssh.org/security.html>
* OpenSSH 2.3.0 and newer are not vulnerable to the "Feb 8, 2001: 
SSH-1 Daemon CRC32 Compensation Attack Detector Vulnerability", RAZOR 
Bindview Advisory CAN-2001-0144. A buffer overflow in the CRC32 
compensation attack detector can lead to remote root access. This 
problem has been fixed in OpenSSH 2.3.0. However, versions prior to 
2.3.0 are vulnerable.
</openssh.org>

<http://razor.bindview.com/publish/advisories/adv_ssh1crc.html>
Issue Date: February 8, 2001
Remotely exploitable vulnerability condition exists in most ssh daemon
  installations (F-SECURE, OpenSSH, SSH from ssh.com, OSSH).
Vulnerable:
 OpenSSH prior to 2.3.0 (unless SSH protocol 1 support is disabled)
Not vulnerable:
 OpenSSH 2.3.0 (problem fixed)

Overview:

An integer-overflow problem is present in common code of recent ssh 
daemons, deattack.c, which was developed by CORE SDI to protect 
against cryptographic attacks on SSH protocol.

Impact:

Insufficient range control calculations (16-bit unsigned variable is 
used instead of 32-bit, which causes integer overflow) in the 
detect_attack() function leads to table index overflow bug. This 
effectively allows an attacker to overwrite arbitrary portions of 
memory. The altered memory locations affect code that is executed by 
the daemon with uid 0, and this can be leveraged to obtain general 
root access to the system.


To reproduce this condition, run your sshd server on localhost under 
gdb with '-d' switch (to avoid forking). Then try (using OpenSSH 
client - ssh.com client software crops the login name):

$ ssh -v -l `perl -e '{print "A"x88000}'` localhost

</razor.bindview.com>

(I have tested the above (though without gdb/-d mode) and it doesn't 
seem to be a problem.)


There has been a security fix for potato in february, with the 
following in the patch:
--- openssh-1.2.3.orig/deattack.c
+++ openssh-1.2.3/deattack.c
@@ -84,7 +84,7 @@
 detect_attack(unsigned char *buf, u_int32_t len, unsigned char *IV)
 {
        static u_int16_t *h = (u_int16_t *) NULL;
-       static u_int16_t n = HASH_MINSIZE / HASH_ENTRYSIZE;
+       static u_int32_t n = HASH_MINSIZE / HASH_ENTRYSIZE;
        register u_int32_t i, j;
        u_int32_t l;
        register unsigned char *c;

When looking at the source of openssh-2.9p2 as used in woody/sid, I 
see the following code in deattack.c:
int
detect_attack(u_char *buf, u_int32_t len, u_char *IV)
{
	static u_int16_t *h = (u_int16_t *) NULL;
	static u_int32_t n = HASH_MINSIZE / HASH_ENTRYSIZE;
	register u_int32_t i, j;
	u_int32_t l;
	register u_char *c;
	u_char *d;

This is in the openssh_2.9p2.orig.tar.gz, not the patch. So it seems 
the problem is already fixed in the original openssh-2.9p2, not only 
openssh-3.0. I've verified that it's the same in the openssh-2.9p2 
from a openssh.org software mirror.


My conclusions:
- ssh versions in potato/woody/sid are not vulnerable (assuming that 
the exploit really uses the deattack problem)
- Information on both www.openssh.org and razor.bindview.com (see 
url's above) is not correct about the version in which the 
vulnerability was closed.

christian.