New ssh Exploit in the Wild

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."

deceit

[Tirel]

Only one remote hole in the default install, in more than 7 years! [openbsd.org]

Oops!

Given that the default install has ssh turned on, will they change it to "two remote holes" ?

How much do you want to bet they'll just sweep it under the carpet and hope people forget? If you follow misc@ carefully you have probably seen it done before. Lets make some noise and force Theo to finally update that!

Questions.

[grub]

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.

Nothing confirmed so far...

[ferratus]

Reading the mailing list, it appears that there's nothing confirmed so far. Let's hope its just a false rumour.

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

[secolactico]

Won't having the sshd wrapped (/etc/hosts.allow, /etc/hosts.deny) help offset the damage somewhat?

Is ths a hoax?

[diodesign]

I just saw the comment [slashdot.org] in the nmap article and got worried. A friend online showed me this post [netsys.com]..

"I wonder if this is in any way related to an incident I heard about on efnet's #openbsd where someone at a european con (hack the planet?) mentioned that details of a new openssh exploit had been taped to the openbsd tent (on the outside) whilst all the openbsd ppl were inside, drunk? I suppose if there is any merit to that story (and I'd rank it as no more than heresay myself, but it does paint a good picture of college level kids :) and it was details of some new vulnerability for which there is an exploit then it has been around for a while...assuming,of course, it is the same "bug"."

I haven't seen anywhere else online go nuts, which is usually how people react to SSH exploits. What's going on?

Suggestions for a newbie?

[johnny1111_23]

Am pretty new to Linux, and am currently running a Lindows 4.0 installation my dad put on my computer.

How worried should I really be about this? And what steps should I be taking (or ask dad to take)? Since I gather Lindows is similar to Debian, should I just look for a Debian tutorial?

Thanks in advance.

Re:deceit

[The Ogre]

Given that this bug appears to be *unexploitable* in OpenBSD, no, I suspect they will *not* change that claim. The hole is only an issue if you you're running OpenSSH on a slightly less secure OS, apparently. Huh, whooda thunk it?

This is dangerous, go upgrade.

[andreas]

I've look at the code, and can confirm that there is a heap overrun bug there. How to exploit it is a little unclear, but rumors are that an exploit exists. If you want to see for yourself, follow what happens in buffer_append_space(), when fatal() is called, and then packet_free() due to that.

Personally, I have upgraded all my systems to lsh [lysator.liu.se]. The code looks much more trustworthy, and I'm sick of upgrading every few months.

OpenSSH is big and fat

[yanestra]

OpenSSH has grown fat over the years, while more and more functionality was integrated, but existing features were kept - for compatibility reasons, and for convenience.
Now we have a big and fat tool that can do nearly everything, but you can go out for bug hunting; there are probably many of them in there.
It would have been a better idea to do a small diet and dis-integrate functions into different tools - like the classic *nix philosophy would suggest.

Coincidence, Or...

[4of12]

So I hear about this ssh exploit the exact same day that my inbox has Markus Friedl's announcement of the release of OpenSSH 3.7.

Either someone on the ssh team is making money from new releases or some black hat, upon downloading 3.7 and seeing the exploit fixed, decided to strike while the iron was still hot (machines weren't yet upgraded).

Re:Telnet

[dasunt]

Of course, if you used telnetd-ssl, you might be correct. :)

[ Caveat: Haven't been following the security problems with telnetd-ssl ]

Re:See this comment for BSD patch and info

[Kingpin]

Your intentions are probably noble, but why should I trust you? Would you trust "you"?

Re:install base

[Minna Kirai]

What a troll. Aiming to trick mods into "Informative", I suppose.

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:Update for debian

[Oestergaard]

It seems that you are right... Just one box. Impressive.

It's impressive in more ways than that - a quick nmap run shows that it has *heaps* of services running, freely available from the net. Among them, postgres, (some) named and SSH.

Apart from the single-point-of-failure problem, why on earth are we running updates from a machine with more holes than a swiss cheese?

Wouldn't it be pretty simple to find an exploit in one of the many services (I bet postgresql will have an overflow or two, having it available from the net is insane to put it mildly), upload a new backdoor'ed SSH package and, say, post a story to slashdot about an SSH hole?

(Yes it does seem that this particular SSH exploit is legitimate, because of references from other sites - the above was just an example).

Just a snippet from the nmap run

21/tcp open ftp
22/tcp open ssh
53/tcp open domain
79/tcp open finger
80/tcp open http
113/tcp open auth
487/tcp open saft
873/tcp open rsync
5432/tcp open postgres

Can somebody enlighten me?

[PinkFluid]

http://www.freebsd.org/cgi/cvsweb.cgi/src/crypto/o penssh/buffer.c.diff?r1=1.1.1.6&r2=1.1.1.7&f=h

I don't see how this fixes any problem ... The code is practically identical, or am I missing something? What's the big deal in calculating the new size in a separate variable? Maybe this is sime kind of DOS attack, not a remote exploit....

Re:Mirror of the vulnerability description

[coyul]

The bug must center around this line:

/* Increase the size of the buffer and retry. */
buffer->alloc += len + 32768;

It looks like the problem here is that buffer->alloc (which presumably stores the size of the buffer) grows on every try, while the actual size of the buffer grows only on successful tries. So you could have a situation where, after a couple of tries, the buffer is 65536, but buffer->alloc is 98304. This could potentially cause another part of the program to run past the actual end of the buffer.

The patch addresses this by only updating buffer->alloc after the new memory has been successfully allocated.

Re:Pot = Kettle = Black

[johnnyb]

None of the rants assumed it couldn't happen.

The nature of _my_ rants at least, include the following:

* UNIX does better at risk minimization (i.e. - chroot jails, more services running as unprivileged users, using processes rather than threads, etc)

* UNIX vulnerabilities are published quickly, and hotfixes are available quickly. In this case, we have a _potential_ vulnerability patched before anyone knows of any way to exploit it. In addition, it made frontpage Slashdot - everyone agrees it's a big deal. This is different from the MS attitude of "sweep it into the next service pack and noone will know".

* I have the source code to the patches, so I can validate whether or not the fix does indeed fix the problem it proposes to, and whether there will be any other impact caused by the patch.

* The patch doesn't require me to reboot anything - I can patch a running system and keep on trucking. Kernel patches should be the only thing that needs a reboot (and, when HURD gets mainstream, we won't even need to then).

* The source code is open to allow more scrutiny. Having the source code available still gives Linux users fewer security-incidents-per-feature than Microsoft while keeping their source closed. Ballmer, I believe, said under oath that giving out the source code to Windows publicly would be a threat to national security.

Nothing about the release of an exploit for Linux changes any of these issues.

Re:Can somebody enlighten me?

[Junta]

Easy, the buffer for a period of time is not as big as the struct indicates. So between the time the buffer size variable is set and the time the realloc is performed, there is a window of opportunity to fill that buffer beyond is alloced boundary if another process/thread goes to put stuff in that buffer at the wrong time.

Also, I'm not sure exactly how 'fatal' the fatal is in there, it could be that it breaks out of the function, but leaves the buffer size parameter at too large a value for the alloc in that buffer.

One or both of those problems is exploitable.

Re:Update for debian

[Oestergaard]

What? No!

vsftpd is defensible, given that it's an FTP server. And that's it.

Why do *I* need SSH, finger, DNS, PostgreSQL, ..., services from that machine? I don't!

If you telnet to a known postgresql server and send it 'asdf', it will reply with 'EFATAL 1: invalid length of startup packet'. When you telnet to security.debian.org on it's postgresql port, it responds with exactly the same message.

So, to answer the other poster: it pretty much looks like a postgresql server - and it sure didn't firewall me away.

Re:Theo's "Pride"

[perry]

I'm on a couple of the lists that should have been informed. As one example, NetBSD's security officer has received no information from the openssh team at all. I'm unaware of other groups having received official word.

If you are aware of a security team that was informed officially, I'd be interested to hear about it.

Re:deceit

[phliar]

This is a bug, not an exploit. There is no known exploit of this bug on OpenBSD. The message on the [Full-Disclosure] list only describes a Denial of Service attack -- flooding the target machines with connections is not ssh's problem.

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"?

duh! coordinated multivendor announcements

[Alejo]

Responsible software vendors release security advisories coordinating with other vendors.

But it is common for irresponsible vendors *cough*redhat*cough*debian*cough to fsck everyone else [securityfocus.com] when they are invited to this groups.

Remember some vendors have multiple versions to update, and a lot of testing before releasing. At least a whole day of work.

Sure, full disclosure ppl would argue that, but maybe there's a middle chance... for example telling ppl some workarounds (if there are) just after knowing the patch, but way before releasing the advisories/patches.

Anyway, I hate here on /. ppl claim stuff like crazy. And instead of blaming the vendor arseholes who shoot others in the back for nothing, blame responsible and respected agents (be it a vendor or someone like Theo)

Deja-vu: Theo's response/behaviour.

[Ricin]

Look at this: http://lists.netsys.com/pipermail/full-disclosure/ 2003-September/010146.html

Remember all the hoopla when everyone *had* to upgrade to privsep immediatly? The lack of details? Theo wining about "hours and hours of hard work" but taking his time to write back and shit all over the person who's merely asking if there's a patch.

Deja-vu. I clearly remember that FreeBSD wasn't even exploitable then but we got told afterwards.

Maybe this is Theo's approach to mass marketing but I find his behaviour close to shizophrenic(sp). Theo the saviour against the rest of the world. It's also amusing to see (some) people go out of their way to *defend* this behaviour. What a cult.

Oh well, just observing... (shrugs)

Re:See this comment for BSD patch and info

[jerryasher]

In patching my systems this morning, and upon reading the sketchy details of the exploit, I am moderately surprised to find that openssh has no method for throttling and shutting down repeated failing attempts for connection.

There is a MaxStartups parameter that sets the number of concurrent ssh sessions, but nothing that says anything like, only allow 3 unsuccessful connections per IP per hour, after an unsuccessful connection delay an open on that IP for 30 seconds, and stuff like that.

What are the best tools on a modern linux distribution to create such a facility?

Re:interesting comment on how to stop it...

[Anonymous Coward]

So you want us to trust a tool when the
developers don't bother to update the
WRONG and outdated documentation?

This isn't some cute gnome utility that
makes penguins dance on your X11 client.

This is a security program. How much
confidence do you have in a tool where the
docs are allowed to slide?

Re:Another place to find the patch/bug advisory

[Dairyland.Net]

The patched buffer.c is available at ftp://ftp.dairyland.net/pub/linux/redhat/patches/o penssh/3.5p1/buffer.c [dairyland.net]. Works with OpenSSH 3.5p1.

Re:See this comment for BSD patch and info

[Anonymous Coward]

Whoa there!!!

Would someone please post the MD5 sum for openssh-3.7p1.tar.gz?

None of these mirrors are worth the time if we can't authenticate what we're downloading somehow ...

exploit a real long shot

[nuttyprofessor]

The bug involves an inconsistency with
the recorded and actual buffer size.
The buffer is allocated off the heap,
but an exploitable overflow really only
works for buffers allocated off of
the stack (where you can overwrite
a subroutine's return address and redirect
program flow). I guess if there are subroutine
addresses in struct's dynamically allocated
off of the heap, then you could redirect
program flow, but I am suspicious of this.

here is how I fixed mine w/out RPMs

[tcpiplab]

Of course, do this at your own risk, but it worked for me on RH8, before the RPMs were realeased, so I did it the old fashioned way.

First you need the latest version of OpenSSL:

http://www.openssl.org/source/openssl-0.9.7b.tar .g z

$tar -zxvf openssl-0.9.7b.tar.gz
$cd openssl-0.9.7b.tar.gz
$make
$make test
$make install

If you haven't stopped sshd yet, then do this:

$/etc/rc.d/init.d/sshd stop

Then you need to get the latest version of OpenSSH:

Go to one of the mirrors listed at:

http://openbsd.groupbsd.org/openssh/portable.htm l

I've found this one to be realiable:

ftp://rt.fm/pub/OpenBSD/OpenSSH/portable/

And download this file:

openssh-3.7p1.tar.gz

Then do the usual:

$tar -zxvf openssh-3.7p1.tar.gz
$cd openssh-3.7p1
$./configure
$make
$make install

And that should fix it. Just restart sshd:

$/etc/rc.d/init.d/sshd start

Then confirm that you're running the latest:

$ssh localhost -V

SSH should be 3.7p1 and SSL should be 0.9.7b

Re:Telnet

[kervel]

same here. i guess telnet is atleast as safe or even safer than ssh in reality ... who ever got owned because of a sniffed plaintext password auth ? and who got owned because a remote root hole in sshd ?

Re:Update for debian

[Cecil]

I'm not sure why debian doesn't use postfix by default. Is the license too free for them?

In all my experience, qmail is the most featureful (but tremendously frustrating, and the license sucks), postfix is almost as featureful, very simple to configure, use, and maintain, and has a great license. exim is last place. Well, unless you consider sendmail which I wouldn't touch with a ten foot pole.

Inane comments by Theo's fanboys

[David Jericho]

Oh god not again... The lengths some people will goto to try and damage Theo's pride.

What a stupid comment. Totally and utterly stupid.

OpenSSH is considered by many to be a core service, right up there with the kernel. If there is an exploitable bug in OpenSSH, there is a bug in OpenSSH. Plain and simple. It becomes important that we know about the potential bugs.

It's not an attempt to discredit Theo, or is it nitpicking at the OpenSSH service. I'd prefer these were found and fixed, rather than them being left unknown in order to keep Theo's ego inflated.