Printable View
update #2:There's another bug found in 3.7. You'll have to upgrade to 3.7.1. Read this: http://www.openssh.org/txt/buffer.adv
update:OpenSSH confirmed a bug in all versions before 3.7 (released today). It's unclear if the bug is exploitable. /update
According to slashdot.org, there's a new SSH bug which has been exploited. The page slashdot links to seems to be suffering the slashdot effect, thus being unreachable. Who has more information on this bug and/or exploit?
Related to this: http://isc.sans.org/diary.html?date=2003-09-16 ?
Thanks. This is what I got from slashdot:
[Full-Disclosure] new ssh exploit?
christopher neitzert [email protected]
Mon, 15 Sep 2003 13:48:34 -0400
The systems in question are FreeBSD, RedHat, Gentoo, and Debian all
running the latest versions of OpenSSH.
The attack makes an enormous amount of ssh connections and attempts
various offsets until it finds one that works permitting root login.
I have received numerous messages from folks requesting anonymity or
direct-off-list-reply confirming this exploit;
The suggestions I have heard are:
Turn off SSH and
1. upgrade to lsh
2. add explicit rules to your edge devices allowing ssh from only-known
hosts.
3. put ssh behind a VPN on RFC-1918 space.
On Mon, 2003-09-15 at 12:02, christopher neitzert wrote:
> Does anyone know of or have source related to a new, and unpublished ssh
> exploit? An ISP I work with has filtered all SSH connections due to
> several root level incidents involving ssh. Any information is
> appreciated.
Hehe.. Based on what I'm reading from the Full Disclosure list, the team that works on SSH are working on a Patch. There also seems to be some indication that it may affection other devices as well (routers/switches).
Is this something to be concerned about in a Win or NT environment?
How about this Xploit affecting switches and routers?
We had a hiccup in our Network today that caused our ARP table to reset itself. The lights on our switches were all blinkingin Unison for about 2 minutes and all connectivity, even out the routers, was unavaliable for about 2 minutes.
The rumoured exploit is supposed to make a -lot- of SSH-connection attempts, to guess some variables.
We are running a GNAT Box Firewall and I think that the Kernel that powers the firmware is Linux Based. What do you think the chances are that we got hit with this earlier this morning. I have never seen anything like it.......
Not a clue. The exploit hasn't even been verified yet.
Possible fix? (Check the URL in the message for possible updates!)
Code:Subject: OpenSSH Security Advisory: buffer.adv
This is the 1st revision of the Advisory.
This document can be found at: http://www.openssh.com/txt/buffer.adv
1. Versions affected:
All versions of OpenSSH's sshd prior to 3.7 contain a buffer
management error. It is uncertain whether this error is
potentially exploitable, however, we prefer to see bugs
fixed proactively.
2. Solution:
Upgrade to OpenSSH 3.7 or apply the following patch.
Appendix:
Index: buffer.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/buffer.c,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- buffer.c 26 Jun 2002 08:54:18 -0000 1.16
+++ buffer.c 16 Sep 2003 03:03:47 -0000 1.17
@@ -69,6 +69,7 @@
void *
buffer_append_space(Buffer *buffer, u_int len)
{
+ u_int newlen;
void *p;
if (len > 0x100000)
@@ -98,11 +99,13 @@
goto restart;
}
/* Increase the size of the buffer and retry. */
- buffer->alloc += len + 32768;
- if (buffer->alloc > 0xa00000)
+
+ newlen = buffer->alloc + len + 32768;
+ if (newlen > 0xa00000)
fatal("buffer_append_space: alloc %u not supported",
- buffer->alloc);
- buffer->buf = xrealloc(buffer->buf, buffer->alloc);
+ newlen);
+ buffer->buf = xrealloc(buffer->buf, newlen);
+ buffer->alloc = newlen;
goto restart;
/* NOTREACHED */
}
Thanks for the response and help. I will keep my eye on it and update this case once I get more information.
Points..............
Debian reacts: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=211205
update - so does FreeBSD: http://lists.freebsd.org/pipermail/f...er/000910.html
No, NT features device aware access controls so even if a remote user is able to access the Admin account (for example) their permissions will be different than an Admin user connecting locally or via a trusted path. (the specifics of this are well off the subject so PM me if you'd like more information.)Quote:
Is this something to be concerned about in a Win or NT environment?
I think exploits like this will continually be a threat to UN*Xland until a more workable PAM is developed (since root ain't going away anytime soon) that could effectively deligate out privileges incrementally. Yeah it would be more of a pain, but really how often do you need more than one or two of root's privileges sets in a single session?
The other solution is a very small and I mean _very small_ serivce that only handles a predefined set of root tasks. This would limit the potential for abuse, but still fails to adequently resolve the issue of trust. Perhaps if it dumped the task into a que with a 15 minute propigation delay and perhaps 5 additional minutes per task, this would make it exceptionally difficult to exploit effectively.
Lots of possibilities, but until some reigns are put on root, at least remotely this issues will constantly be lurking around ever corner and patching isn't gonna make them go away.
catch
Any ofcourse lets not forget redhat
https://rhn.redhat.com/errata/RHSA-2003-279.html
Patch up!
Mandrake Updates Check here : http://www.mandrakesecure.net/en/adv...MDKSA-2003:090
To upgrade automatically, use MandrakeUpdate.
If you want to upgrade manually, download the updated package(s) from one of their FTP server mirrors and upgrade with "rpm -Fvh *.rpm".
Slackware has released an update too - now on all the major mirrors ....
Oh the joy of the *nix community .... quick to jump on the bugs and squash them before they become a plague :)
Beware! There's another bug found in OpenSSH. You'll have to update to 3.7.1 (just 3.7 won't do). Read the advisory here: http://www.openssh.org/txt/buffer.adv
Shouldn't that read: "Oh the joy of the *nix community .... always treating just the symptom"? ;) (Not that Windows is any better, ah the joys of COTS operating systems.)Quote:
"Oh the joy of the *nix community .... quick to jump on the bugs and squash them before they become a plague"
catch
(http://www.antionline.com/showthread...hreadid=248600)Quote:
Originally posted here by Guus
Beware! There's another bug found in OpenSSH. You'll have to update to 3.7.1 (just 3.7 won't do). Read the advisory here: http://www.openssh.org/txt/buffer.adv
Quote:
To: BugTraq
Subject: Portable OpenSSH 3.7.1p2 released
Date: Sep 23 2003 12:39PM
Author: Damien Miller <djm cvs openbsd org>
Message-ID: <[email protected]>
Portable OpenSSH 3.7.1p2 has just been released. It will be available
from the mirrors listed at http://www.openssh.com/portable.html shortly.
Please note that this is a release to address issues in the portable
version only. The items mentioned below do not affect the OpenBSD
version.
OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0
implementation and includes sftp client and server support.
We would like to thank the OpenSSH community for their continued
support to the project, especially those who contributed source and
bought T-shirts or posters.
We have a new design of T-shirt available, more info on
http://www.openbsd.org/tshirts.html#18
For international orders use http://https.openbsd.org/cgi-bin/order
and for European orders, use http://https.openbsd.org/cgi-bin/order.eu
Security Changes:
=================
Portable OpenSSH version 3.7p1 and 3.7.1p1 contain multiple
vulnerabilities in the new PAM authentication code. At least one of
these bugs is remotely exploitable (under a non-standard
configuration, with privsep disabled).
OpenSSH 3.7.1p2 fixes these bugs. Please note that these bugs do not
exist in OpenBSD's releases of OpenSSH.
Changes since OpenSSH 3.7.1p1:
==============================
* This release disables PAM by default. To enable it, set "UsePAM yes" in
sshd_config. Due to complexity, inconsistencies in the specification and
differences between vendors' PAM implementations we recommend that PAM
be left disabled in sshd_config unless there is a need for its use.
Sites using only public key or simple password authentication usually
have little need to enable PAM support.
* This release now requires zlib 1.1.4 to build correctly. Previous
versions have security problems.
* Fix compilation for versions of OpenSSL before 0.9.6. Some cipher modes
are not supported for older OpenSSL versions.
* Fix compilation problems on systems with a missing or lacking inet_ntoa()
function.
* Workaround problems related to unimplemented or broken setresuid/setreuid
functions on several platforms.
* Fix compilation on older OpenBSD systems.
* Fix handling of password-less authentication (PermitEmptyPasswords=yes)
that has not worked since the 3.7p1 release.
Checksums:
==========
- MD5 (openssh-3.7.1p2.tar.gz) = 61cf5b059938718308836d00f6764a94
Reporting Bugs:
===============
- please read http://www.openssh.com/report.html
and http://bugzilla.mindrot.org/
OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt,
Kevin Steves, Damien Miller, Ben Lindstrom, Darren Tucker and Tim Rice.