Bugtraq mailing list archives
Re: ssh-1.2.27 exploit
From: core.lists.bugtraq () CORE-SDI COM (Beto)
Date: Wed, 15 Dec 1999 18:30:28 -0300
Jarek Kutylowski wrote:
I have now worked on the ssh-1.2.27 rsaref buffer overflow and consider ssh now as quite immune. It is of course possible to crash sshd, but a real attack is, in my opinion, impossible. Doing an overflow we must provide a buffer of 136 bytes length (the input_data buffer is 128 bytes + 4 bytes for the EBP and 4 bytes for the EIP). Everything works fine until we reach the RSAPrivateDecrypt function in rsaref. This function checks the variable input_len, which is the length of the buffer (in our case it is minimum 136) against the variable modulus_len, which is 128. When this check fails (and it does), RSAPrivateDecrypt returns error, causing sshd to fall into a fatal error.
That's right, but you can also overflow the rsa_private_decrypt's arguments: void rsa_private_decrypt(MP_INT *output, MP_INT *input, RSAPrivateKey *key) { unsigned char input_data[MAX_RSA_MODULUS_LEN]; unsigned char output_data[MAX_RSA_MODULUS_LEN]; unsigned int input_len, output_len, input_bits; R_RSA_PRIVATE_KEY private_key; key points to a RSAPrivateKey structure who has the modulus_len value. So, to make the exploit work you have to overflow this pointer to a new key with the correct modulus_len so the check you pointed before does not return error. You can't put the fake key into the buffer 'cause it's too short, so you have to find another place to put it in. That place is the incoming_packet.buf variable. There you have 4kb (if i remember well) to store whaterver you want. Actually the exploits sends the fake key and the shell code after the crypted data. The first overflow makes key point to the fake key into incoming_packet.buf and the second one in NN_Decode() overflows RSAPrivateDecrypt()'s return address to point into incoming_packet.buf whereis the shell_code.
If you have any other suggestions, I'd like to hear them.
-- ==============================[ CORE Seguridad de la Informacion S.A. ]======= Alberto Soliño WWW :www.core-sdi.com Consultor Email :asolino () core-sdi com Pte. Juan D. Peron 315 4p UF 17 TE : +54-11-4331-5409 CP 1038 Capital Federal FAX : +54-11-4331-5402 Buenos Aires, Argentina ============================================================================== --- For a personal reply use asolino () core-sdi com
Current thread:
- sadmind exploits (remote sparc/x86) Marcy Abene (Dec 10)
- Re: sadmind exploits (remote sparc/x86) Erik Fichtner (Dec 10)
- Re: sadmind exploits (remote sparc/x86) Lamont Granquist (Dec 10)
- Irix and TCP implementation TeSd (Dec 10)
- 64bit Sol7 on Ultra1 < 200mhz bug Jake Luck (Dec 11)
- VDO Live Player 3.02 Buffer Overflow UNYUN (Dec 12)
- ssh-1.2.27 exploit Jarek Kutylowski (Dec 13)
- Re: ssh-1.2.27 exploit Iván Arce (Dec 13)
- Re: ssh-1.2.27 exploit Beto (Dec 15)
- FreeBSD 3.3 xsoldier root exploit Brock Tellier (Dec 15)
- Xsoldier xploit (was: FreeBSD 3.3 xsoldier root exploit) Spidey (Dec 15)
- BindView Security Advisory: Vulnerability in Windows NT's SYSKEY feature BindView Security Advisory (Dec 16)
- Cisco Security Advisory: Cisco Cache Engine Authentication Vulnerabilities security-alert () CISCO COM (Dec 16)
- Reinventing the wheel (aka "Decoding Netscape Mail passwords") Vanja Hrustic (Dec 15)
- Re: Reinventing the wheel (aka "Decoding Netscape Mail passwords") John Viega (Dec 16)
- Re: Reinventing the wheel (aka "Decoding Netscape Mail passwords") Tim Hollebeek (Dec 16)
- Re: Reinventing the wheel (aka "Decoding Netscape Mail passwords") Aleph One (Dec 16)
- ssh/rsaref bo exploit code Iván Arce (Dec 16)
- Re: Reinventing the wheel (aka "Decoding Netscape Mail passwords") Rob Jones (Dec 16)
- Re: sadmind exploits (remote sparc/x86) Lamont Granquist (Dec 10)
- Re: sadmind exploits (remote sparc/x86) Erik Fichtner (Dec 10)