4580032 1999-12-13 23:32 /39 rader/ Postmaster
Mottagare: Bugtraq (import) <8887>
Ärende: ssh-1.2.27 exploit
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: bugtraq@securityfocus.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID: <Pine.LNX.4.21.9912130919050.1146-100000@main.tenet.pl>
Date: Mon, 13 Dec 1999 09:27:05 +0100
Reply-To: Jarek Kutylowski <jarekk@TENET.PL>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Jarek Kutylowski <jarekk@TENET.PL>
X-To: bugtraq@securityfocus.com
To: BUGTRAQ@SECURITYFOCUS.COM
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.
A solution for this problem would be to overflow the input_len. On my
machine this variable normally gets optimized, so there is no
way. Anyway, when it is written to stack, it is saved much more
before input_data, so it is unaccessible.
If you have any other suggestions, I'd like to hear them.
-- Jarek Kutylowski
<jarekk@tcs.uni.wroc.pl>
<jarekk@tenet.pl>
Get my PGP public key by running "finger jarekk@tenet.pl"
or by WWW from "www.tenet.pl/~jarekk/pgp.txt" !!!
(4580032) ------------------------------------------(Ombruten)
4583339 1999-12-14 18:45 /78 rader/ Postmaster
Mottagare: Bugtraq (import) <8899>
Ärende: sshd1 allows unencrypted sessions regardless of server policy
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: bugtraq@securityfocus.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID: <19991214164332.A3513@faui01.informatik.uni-erlangen.de>
Date: Tue, 14 Dec 1999 16:43:32 +0100
Reply-To: Markus Friedl <Markus.Friedl@INFORMATIK.UNI-ERLANGEN.DE>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Markus Friedl <Markus.Friedl@INFORMATIK.UNI-ERLANGEN.DE>
X-To: bugtraq@securityfocus.com
To: BUGTRAQ@SECURITYFOCUS.COM
[I am posting this here since nobody seems to take care of ssh-1.2.27]
While working on OpenSSH I discovered the following defect in
ssh-1.2.27, OpenSSH and other related implementations of SSH1:
A malicious ssh-client can force a server to use the so
called cipher "none" even if the server-policy does not
permit this.
In the SSH1 protocol, during connection setup, the server sends a
list of supported ciphers to the client. This list represents the
server policy and includes the ciphers the server is going to accept.
Usually the client chooses one cipher from this list and sends its
choice back to the server.
However, in all these implementations, the server does _not_ check
whether the cipher chosen by the client is included in the list of
previously offered ciphers.
According to README.CIPHERS from recent ssh-1.2.2x releases login
sessions 'encrypted' with cipher "none" are disabled by default:
"This cipher is intended only for testing, and should not
be enabled for normal use. Using no encryption makes SSH
vulnerable to network-level attacks (such as connection
hijacking). There are also more subtle ways to exploit
using no encryption, and servers should not allow such
connections at all except when testing the protocol.
[...]
You can allow "none" encryption by giving the --with-none
option to configure. Using no encryption is not allowed by
default.
This is wrong.
Because passphrase-less hostkeys are 'encrypted' with cipher "none"
the code for this cipher is always compiled into the programs. This
way the client is free to choose "none" and no server will complain.
The current version OpenSSH-1.2.1 is not vulnerable. The obvious
fix can be found below. A patch for the versions of OpenSSH shipped
with OpenBSD-2.6 is available from
http://www.openbsd.org/errata.html#sshjumbo
Information on OpenSSH can be found at http://www.openssh.com/
Index: sshd.c
===================================================================
--- sshd.c 1999/12/06 20:15:30 1.68
+++ sshd.c 1999/12/07 13:38:05
@@ -869,8 +869,11 @@
/* Read clients reply (cipher type and session key). */
packet_read_expect(&plen, SSH_CMSG_SESSION_KEY);
- /* Get cipher type. */
+ /* Get cipher type and check whether we accept this. */
cipher_type = packet_get_char();
+
+ if (!(cipher_mask() & (1 << cipher_type)))
+ packet_disconnect("Warning: client selects unsupported cipher.");
/* Get check bytes from the packet. These must match those we
sent earlier with the public key packet. */
(4583339) ------------------------------------------