Slashdot Log In
New ssh Exploit in the Wild
Posted by
CmdrTaco
on Tue Sep 16, 2003 10:07 AM
from the brace-for-impact dept.
from the brace-for-impact dept.
veg writes "In the last few hours there have been several reports of a new ssh bug, with an exploit seemingly in the wild. Oh god not again... The lengths some people will goto to try and damage Theo's pride." Update: 09/17 00:24 GMT by T : friscolr writes "Hot on the heels of rev 1 of the buffer.adv advisory, here is revision 2, which fixes more than revision 1 did. Also see the 3.7.1 release notes."
This discussion has been archived.
No new comments can be posted.
New ssh Exploit in the Wild
|
Log In/Create an Account
| Top
| 754 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
|
2
Uh oh (Score:5, Funny)
Another place to find the patch/bug advisory (Score:5, Informative)
Re:Uh oh - no funny (Score:5, Funny)
Re:deceit (Score:4, Informative)
# dmesg | head -n2
OpenBSD 3.4-current (GENERIC) #62: Tue Sep 12 22:49:18 MDT 2003
deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/c
Re:MOD PARENT DOWN (Score:5, Funny)
(http://syberghost.livejournal.com/)
It'd serve you right if he gave you one.
Re:deceit (Score:4, Informative)
And as comparison, how many patches do windows users normally need to install over the 'default install' to get it secure and close every hole in the default setup? Methinks slightly more than 1 or 2...
Re:deceit (Score:5, Funny)
(http://danormsby.googlepages.com/)
Re:deceit (Score:4, Interesting)
(http://www.drones.com/)
Besides, what have they "swept under the carpet"? What do you mean "you have probably"?Just because you seem to have something personal with Theo going on, we're supposed to take your word for this "deceit"?
Re:deceit (Score:4, Informative)
(http://www.mklinux.org/)
OpenSSH refuses to allocate a buffer over a certain size, but doesn't set the buffer size value back to its previous value. When this occurs, OpenSSH immediately calls fatal() to clean up and exit. The connection is closed, and the buffer is not reused.
The problem is that the cleanup code will, in some cases, attempt to zero the block at the larger size, resulting in OpenSSH crashing.
Because no data other than zeroes is every written to this buffer after the failed allocation (unless the FreeBSD folks missed something), this bug cannot be exploited except as a denial-of-service attack unless combined with some other exploit that allowed you to overwrite the exception handling vectors and add arbitrary code (in which case, there are probably much easier ways to perform the exploit).
See this comment for BSD patch and info (Score:5, Informative)
(Last Journal: Monday May 22 2006, @03:55PM)
Re:See this comment for BSD patch and info (Score:5, Informative)
(http://www.briangannon.com/ | Last Journal: Tuesday October 01 2002, @09:00AM)
since RH hasn't released any yet...
it's backported from the 9.0 update ssh SRPM.
my bandwidth is VERY limited... so AIM ME at "Swell500" and i'll send ya a link to grab them until RH releases official patches.
ChiefArcher
Trust me... View the srpm (Score:5, Informative)
(http://www.briangannon.com/ | Last Journal: Tuesday October 01 2002, @09:00AM)
you can always grab it and see for yourself..
I only changed buffer.c
Feel free to see for yourself..
I had to make all of these this morning to patch our systems..
ChiefArcher
intentions are noble and MIRROR now (Score:5, Informative)
(http://www.briangannon.com/ | Last Journal: Tuesday October 01 2002, @09:00AM)
you have an email address to...
and a resume www.briangannon.com
and the Source RPMS.
http://stradlin.com/ssh [stradlin.com]
if you do a diff on the sources, you will see I only edited buffer.c
my intentions are completely noble.
How can you really trust Redhat? One of the disgruntled developers could put a backdoor in a patch?
ChiefArcher
Re:interesting comment on how to stop it... (Score:5, Informative)
(http://www.gwydiondylan.org)
lsh has grown mature since then, and has an excellent code quality. I recommend it. Any day over OpenSSH, after having looked at the code of both projects. Up-to-date documentation, as on the web page, or the README inside the tarball, doesn't contain the warning.
Fixed that ancient LSH README (Score:5, Informative)
Questions. (Score:5, Interesting)
(http://www.grub.net/blog/index.html | Last Journal: Wednesday June 27, @08:48AM)
I have to wonder if UsePrivilegeSeparation was enabled. (see the manpage [openbsd.org])
One message in the thread indicates it is but this isn't first-hand knowledge. If PrivSep was enabled then is OpenBSD immune to this attack due to other parts of the OS being hardened (much like the zlib hole a few months back)? Also are these default installations or are they "tweaked"? As an aside, PermitRootLogin defaults to enabled, something I always disable as I have no need for it.
Even if this does count as a new remote hole in OpenBSD, it's still a phenomenal track record they can be proud of.
Re:Questions. (Score:4, Informative)
(http://supercheetah.livejournal.com/ | Last Journal: Friday March 04 2005, @03:24AM)
That means that Debian's default configuration for sshd is also secure.
CRAP! (Score:3, Informative)
(http://www.shadyproject.net/)
The advisory itself says The systems in question are FreeBSD, RedHat, Gentoo, and Debian all running the latest versions of OpenSSH. So i'm going to assume that OS X is affected as well.
Public Service (Score:5, Funny)
Patch (Score:5, Informative)
Full Disclosure (Score:4, Informative)
christopher neitzert chris@neitzert.com
Mon, 15 Sep 2003 13:48:34 -0400
More on this;
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.
The "Full Disclosure" message is stupid (Score:5, Insightful)
(http://www.welsh-buck.org/jbuck/)
It appears that the OpenSSH people found this bug first, and released a fix in version 3.7. People who studied this fix then found the exploit. So it's stupid for this guy to tell people "upgrade to lsh", since the whole reason his buds know about this bug is because 3.7 fixes it.
Debian? (Score:4, Informative)
(http://digitalelf.net/)
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.
Odd. I run Debian on all of my systems and PermitRootLogin is set to no on all of them. Sarge and Sid also have UsePrivilegeSeparation set to yes by default.
Telnet (Score:5, Funny)
(Last Journal: Wednesday September 28 2005, @12:05PM)
Re:very early (Score:4, Insightful)
It also may give those who need it on something to watch for until a patch does come out.
Re:very early (Score:5, Insightful)
(http://slashdot.org/)
Really?
How about hearing about it when you find your machines rooted?
Even though there is no patch available (yet), this heads-up is extremely valuable, as it allows people who cannot afford to be compromised to shut down or appropriately filter SSH on their systems.
Re:very early (Score:5, Insightful)
Even though there is no patch available (yet)
There is a patch available, as well as it being fixed in 3.7, which was just released this morning. That's the point of all of this. The mention of the bug was in the 3.7 release notes, i believe.
Nothing confirmed so far... (Score:3, Interesting)
(http://www.jgrenier.com/)
There's only one guy that says it its ISP has blocked all incoming SSH connection due to "several root level incidents".
One guy did say that there was a bug somewhere and that a patch existed...No one knows what patch or where it is though.
Let's hope to publish this one quickly before there's any ral damage done.
Wrapping defense (Score:4, Interesting)
(Last Journal: Wednesday March 27 2002, @09:26PM)
It'll help, and also: (Score:5, Informative)
(http://frobnosticate.com/ | Last Journal: Friday October 26 2001, @10:05AM)
DenyUsers *
AllowUsers you@your_ip_address
(and restart sshd)
You can also firewall the port off. I've done a hodge-podge of these solutions on different systems I admin until I can actually get the 3.7p1 source from the mirrors (they dont' seem to have it yet).
ERROR: MOD (my) PARENT DOWN, MOD THIS UP INSTEAD (Score:5, Informative)
(http://frobnosticate.com/ | Last Journal: Friday October 26 2001, @10:05AM)
Sorry.
AllowUsers you@your_ip_address
Remember, always test making a new ssh connection before logging out of your existing one, after restarting sshd.
Re:It'll help, and also: (Score:4, Informative)
It is better explained as "AllowUsers localAccount@remote_ip_address". It means: "Allow SSH connections from anybody at remote_ip_address to connect to localAccount." (Of course the remote user still must authenticate successfully.)
The syntax unfortunately looks like it specifies a remote user. It doesn't. It defines a relationship between a remote IP address and a local user.
Trust me, I wrote the book [snailbook.com]. :-)
Re:Is ths a hoax? (Score:4, Informative)
(http://www.sbce.org/ | Last Journal: Thursday February 12 2004, @07:27PM)
technoid
Re:install base (Score:5, Interesting)
Any "linux user" who has openssh open to the world is a huge dumbass. What part of "firewall rules" don't you understand?
How would you suggest it be configured then? Just turn off remote login entirely? Or what other "firewall rule" could help in this situation?
I assume you are suggesting that people only allow ssh access from a specific, previously-known host. That removes much of ssh's utility (no more checking your system from a laptop in the hotel room), and even that sacrifice is not enough to be protective!
An attacker sniffing packets at your ISP can learn exactly which addresses you accept ssh connections over. Then he can spoof from that same address, and go right through the firewall.
The only way to protect yourself from unwanted outside connections is with correct crypto code.
Re:install base (Score:5, Funny)
That's okay, I will.
I bet this guy's life that a server on the bottom of the ocean is secure.
Bits and pieces so far... (Score:5, Informative)
(http://unthought.net/)
It will be 3.7p1 for us non-OpenBSD people.
It is a patch to one file, buffer.c, which fixes some allocation/offset stuff.
It seems that privilege separation does *not* help here - so get them systems patched (and firewalled)!
Update for debian (Score:5, Informative)
(http://unthought.net/)
For anyone running debian stable:
apt-get update
apt-get upgrade
Re:Update for debian (Score:4, Informative)
(http://www.webme-eng.com/)
For i386 the exact link is http://incoming.debian.org/ssh_3.6.1p2-6.0_i386.d
Re:Update for debian (Score:5, Insightful)
(http://www.jukie.net/~bart/ | Last Journal: Wednesday July 24 2002, @08:29AM)
bug 211205 [debian.org], which deals with this expoit, was resolved in 2h after the announcement. I had my box patched 15min after the slashdot story hit.
Really good stuff.
For Gentoo (Score:5, Insightful)
(http://www.tygerteam.com/)
- cp openssh-3.6.1_p2.ebuild openssh-3.7_p1.ebuild
- emerge --update openssh
The emerge will fetch the file and complain that there is no digest.- ebuild openssh-3.7_p1.ebuild digest
- emerge --update openssh
Just tested it here, worked fine.Pat
Re:For Gentoo (Score:5, Informative)
It renames the gentoo ebuild, which uses it's own name to figure out what to fetch and install.
So basically a 3.7_p1 named ebuild goes out and fetches the new 3.7 openssh package, compiles it and installs it.
Re:Mirror of the vulnerability description (Score:5, Interesting)
The bug must center around this line:
It looks like the problem here is that buffer->alloc (which presumably stores the size of the buffer) grows on every try, w