[Full-Disclosure] The remote Openssh User-Level-Denial-Of-Service
From: Alpt (alpt_at_freaknet.org)
Date: 09/19/04
- Previous message: Nick FitzGerald: "Re: [Full-Disclosure] ZIP Attachment"
- Next in thread: 3APA3A: "Re: [Full-Disclosure] The remote Openssh User-Level-Denial-Of-Service"
- Reply: 3APA3A: "Re: [Full-Disclosure] The remote Openssh User-Level-Denial-Of-Service"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: primavera@freaknet.org Date: Sun, 19 Sep 2004 15:05:23 +0200
-------------------------------------------------------------------------------
Security Advisory SA 200409-01
-------------------------------------------------------------------------------
Severity: Normal
Title: user-level-denial-of-service
Date: Septer 03, 2004
ID: 200409-01
Authors: alpt <alpt@freaknet.org>, valvoline <valvoline@freaknet.org>
-------------------------------------------------------------------------------
Synopsis
--------
A flawless into connections management and keys handshake was discovered into
openssh daemon. This could allow any malicious user to attach the service,
making it unusable.
Affected packages
-----------------
OpenSSH 3.8p1 (and later versions)
Older version can be bugged too.
Description
------------
Sshd, and all others daemons based upon the same behaviour of connection,
contains a problem regarding the MAX connections allowed. If a malicious
user can open MAX connections to the server's daemon, than this will get
in a classical Denial Of Service.
Even this's not an hot/fresh news, we propose a well self-contained proof
of concepts for sshd and a possible clean solution for the sshd service.
The one proposed is an hard-coded solution into the authentication/login
part of the sshd.c code. However, the behaviour and the method of
connections-handling can be used both for sshd or *any* other service
containing this problem (proftpd, is bugged too).
The well known solution to this kind of attach can be a burst limit into
firewall rules and/or any other kind of traffic shaping at TCP stack and/or
kernel lavel. However, we think that this solution is slightly unefficient
for several reasons including kernel poor-performances and few control over
the single services. Also in all tests that we've done, even with a burst-limit
included in iptables level, sshd still fell in DoS.
Let's look at sshd. It contains some routines used for user authentication
and keys management during user logon. During handshake the system make a
fork, using the returned child to serve the client and making the parent
able to receive other requests. During this phase, the system waits for an
user input and then it validates the user password and/or public key.
At this point there're neither user connection control nor control about
max opened sockets per user.
A malicious user can attack the server opening more connections than the
maximum supported by the operating system, creating a denial of service.
A simple bash script will illustrate the flawless. Beware that this proof
of concept will saturate the client machine! For an efficient version of
the proof-of-concept, just apply the included patch to ssh client and set
the maximum wished connections.
-->CUT HERE<--
#!/bin/sh
TRUE=1;
while [ $TRUE ]
do
ssh 10.10.1.200 &
done
-->CUT HERE<--
Impact
------
Any user on any machine has the ability to get in DoS a remote ssh daemon,
using a simple bash script or a patched version of ssh client (see above).
Workaround
----------
Apply the patch or wait for an official patch from openssh.
Note: The patch removes the MaxStartups option and adds two new options for
the sshd_config file: MaxConnections and MaxAcceptsPerHost.
See the ./sshd_config.5 man page for more info.
Repository
----------
The document you are currently reading is here:
http://www.freaknet.org/alpt/src/Openssh-UlDoS/sa200409-19.txt
You can download the patch for openssh here:
http://www.freaknet.org/alpt/src/Openssh-UlDoS/patch-ssh-3.8.1p1-uDoS.patch
the PoF patch is here:
http://www.freaknet.org/alpt/src/Openssh-UlDoS/pof-uDoS-openssh-3.8.1p1.patch
If you are looking for the right version of Openssh download this:
http://www.freaknet.org/alpt/src/Openssh-UlDoS/openssh-3.8.1p1.tar.gz
If you want to check the md5sum of the files use these:
http://www.freaknet.org/alpt/src/Openssh-UlDoS/openssh-3.8.1p1.tar.gz.md5
http://www.freaknet.org/alpt/src/Openssh-UlDoS/patch-ssh-3.8.1p1-uDoS.patch.md5
http://www.freaknet.org/alpt/src/Openssh-UlDoS/pof-uDoS-openssh-3.8.1p1.patch.md5
-- :wq! "I don't know nothing" The One Who reached the Thinking Matter '.' [ Alpt --- Freaknet Medialab ] [ GPG Key ID 441CF0EE ] [ Key fingerprint = 8B02 26E8 831A 7BB9 81A9 5277 BFF8 037E 441C F0EE ] -- !(v^v)?spj:vrl; keyID=1d67b4dd;
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- text/plain attachment: patch-ssh-3.8.1p1-uDoS.patch
- text/plain attachment: pof-uDoS-openssh-3.8.1p1.patch
- text/plain attachment: patch-ssh-3.8.1p1-uDoS.patch.md5
- text/plain attachment: pof-uDoS-openssh-3.8.1p1.patch.md5
- application/pgp-signature attachment: stored
- Previous message: Nick FitzGerald: "Re: [Full-Disclosure] ZIP Attachment"
- Next in thread: 3APA3A: "Re: [Full-Disclosure] The remote Openssh User-Level-Denial-Of-Service"
- Reply: 3APA3A: "Re: [Full-Disclosure] The remote Openssh User-Level-Denial-Of-Service"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
