Slashdot Mirror
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."
C:\>
"upgrade" to GNU lsh or block SSH from everyone except known hosts (the VPN option does basically the same thing).
Looks like its time to turn the port forwarding on my router off, and wait for apple to provide a patch.
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.
Look out honey cause I'm usin' technology
Ain't got time to make no apologies
Link to a patch.
[Full-Disclosure] new ssh exploit?
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.
Yes, there is a vuln. in 3.6. You need to upgrade to 3.7 which was released today, to be safe (well, 'safer' anyway).
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)!
This has already been posted and a fix (upgrade to 3.7) has been posted to www.deadly.org
This guy is way out there
There is a patch, but the server that the advisory referenced on the SANS posting is on went down hard while I was in the middle of getting the page, so I only managed to get part of it (thanks, slashdot!) The advisory also indicated that openSSH 3.7 isn't affected.
If I have been able to see further than others, it is because I bought a pair of binoculars.
PermitRootLogin is enabled so you can login after a remote install, but the install guide tells you disabling it is one of the first thing you should do after you successfully boot and make a normal user account.
Patches are already available, for example from the FreeBSD CVS web. Personally, I'd rather apply it now than waiting for a detailed analysis of the exploit...
Programming can be fun again. Film at 11.
Lindows is similar in the fact it's based on Linux, but the security model is different (forcing all users to root priviliges). I wonder if sshd runs as root as well?
% apt-get source ssh/ openssh/buffer.c.diff?r1=1.1.1.6&r2=1.1.1.7&f=h&f= u' | \ ..
% cd openssh-3.6.1p2 # this in unstable, might be a different version in testing/stable
% wget --user-agent="mozilla" -O - \
'http://www.freebsd.org/cgi/cvsweb.cgi/src/crypto
patch -p3
% fakeroot debian/rules binary
% cd
And you should have new packages ready to be installed..
An updated ssh package just hit the Debian security mirrors.
For anyone running debian stable:
apt-get update
apt-get upgrade
Simple question: If it's Lindows, a) is it running sshd in the first place? And if so, b) *why* is it running sshd, since, in my estimation, an average Lindows user probably doesn't need sshd running. Of course, if you don't need sshd (since you don't access your box remotely), the obvious thing to do is kill and uninstall it (apt-get remove sshd), since it's just one more thing that could have a remote exploit in it.
Now, if you feel you need sshd, but can go without for a while, uninstall sshd in the short term and wait for an upgrade for your OS, at which point you can safely reinstall (it's a simple "apt-get install sshd").
A patch for Debian stable is available already. If you're running Debian on a server and have ssh installed, "apt-get update; apt-get upgrade" should pick it up. The new package version is 1:3.4p1-1.1.
-Stephen
I'm installing it as we speak on all my Woody machines.
apt-get update
apt-get upgrade
"City hall" in German is "Rathaus" Kinda explains a few things......
... can be found here http://archives.neohapsis.com/archives/fulldisclo
As far as I know Lindows does not run any services by default. Hence sshd should not be running. To check type
ps -Af |grep sshd
and see if there is an entry for it. If so then turn it off (does Lindows have a GUI for configuring services?).
You should note that comment came from Darren Reed (of IPFilter fame), who is not a fan of Theo. After the arguements over the IPFilter licensing, a comment like this coming from him doesn't suprise me at all.
technoid
Two wrongs don't make a right, but 3 lefts do - Lew of GO magazine
Rather than subject someone's server (like mine!) to a slashdotting, here's the full text of the announcement (slightly mangled to sneak past the lameness filter).
Subject: OpenSSH 3.7 released
Date: Tue, 16 Sep 2003 14:07:00 +0200
From: Markus Friedl
To: openssh-unix-dev _at_ mindrot.org
OpenSSH 3.7 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly.
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:
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.
OpenSSH 3.7 fixes this bug.
Changes since OpenSSH 3.6.1:
* The entire OpenSSH code-base has undergone a license review. As a result, all non-ssh1.x code is under a BSD-style license with no advertising requirement. Please refer to README in the source distribution for the exact license terms.
* Rhosts authentication has been removed in ssh(1) and sshd(8).
* Changes in Kerberos support:
- KerberosV password support now uses a file cache instead of a memory cache.
- KerberosIV and AFS support has been removed.
- KerberosV support has been removed from SSH protocol 1.
- KerberosV password authentication support remains for SSH protocols 1 and 2.
- This release contains some GSSAPI user authentication support to replace legacy KerberosV authentication support. At present this code is still considered experimental and SHOULD NOT BE USED.
* Changed order that keys are tried in public key authentication. The ssh(1) client tries the keys in the following order:
1. ssh-agent(1) keys that are found in the ssh_config(5) file
2. remaining ssh-agent(1) keys
3. keys that are only listed in the ssh_config(5) file
This helps when an ssh-agent(1) has many keys, where the sshd(8) server might close the connection before the correct key is tried.
* SOCKS5 support has been added to the dynamic forwarding mode in ssh(1).
* Removed implementation barriers to operation of SSH over SCTP.
* sftp(1) client can now transfer files with quote characters in their filenames.
* Replaced sshd(8)'s VerifyReverseMapping with UseDNS option. When UseDNS option is on, reverse hostname lookups are always performed.
* Fix a number of memory leaks.
* Support for sending tty BREAK over SSH protocol 2.
* Workaround for other vendor bugs in KEX guess handling.
* Support for generating KEX-GEX groups (/etc/moduli) in ssh-keygen(1).
* Automatic re-keying based on amount of data sent over connection.
* New AddressFamily option on client to select protocol to use (IPv4 or IPv6).
* Experimental support for the "aes128-ctr", "aes192-ctr", and "aes256-ctr" ciphers for SSH protocol 2.
* Experimental support for host keys in DNS (draft-ietf-secsh-dns-xx.txt). Please see README.dns in the source distribution for details.
* Portable OpenSSH:
- Replace PAM password authentication kludge with a more correct PAM challenge-response module from FreeBSD.
- PAM support may now be enabled/disabled at runtime using the UsePAM directive.
- Many improvements to the OpenSC smartcard support.
- Regression tests now work with portable OpenSSH. Please refer to regress/README.regress in t
$ find
An OpenSSH Security Advisory was just posted about this.
Is it? I've successfully exploited my sshd (thank God for easy filtering with PF!)
o mpile/GENERIC
# 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
To be found at:
http://unthought.net/ssh-vuln.html
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?
/etc/init.d/sshd, not sure about Lindows). It will come back on after a reboot though, so you'll want a more permanent solution, which involves moving one of the startup scripts in a /etc/init.d/ subdirectory. If you have trouble, reply and we'll get you sorted out.
If you don't log on to your computer from another machine at school or wherever, then the safest thing would be to ensure that the ssh daemon is disabled. You can test this by just trying a "ssh localhost" at a command prompt. If you get a "Connection Refused" message, you're probably fine. To make sure, try executing "/etc/init.d/ssh stop" as root (might also be
Cheers,
Mouser
If you don't want to wait for the official ebuild:
/usr/portage/net-misc/openssh/
cd
cp openssh-3.6.1_p2.ebuild openssh-3.7_p1.ebuild
emerge -f openssh-3.7_p1.ebuild
ebuild openssh-3.7_p1.ebuild digest
emerge openssh-3.7_p1.ebuild
That's a partial defense, and relates to a suggestion made in the mailing list announcement of the vulnerability.
However, if you're a paranoid or pessimistic kind of person, you shouldn't rely on hosts.allow to protect you.
Assuming that your ISP is taken over (either by hackers, or the FBI), they can re-number any internet packets destined to you. The hosts_access system will have no way to tell that a datastream is from a spoofed source. The "source address" field of IP packets can be falsified, and there's no way to tell.
However, in normal circumstances ssh can do a better job of verifying remote identity, by using more information than IP headers provide. It checks fingerprints of keys on the remote system, for example. But can we be sure that this feature is still working today, and hasn't been defeated by the latest exploit? That won't be known without expert analysis.
wget from: http://security.debian.org/pool/updates/main/o/ope nssh/ssh_3.4p1-1.1_i386.deb
then dpkg -i the resulting file.
I've released the SOURCE RPM...
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
No it does not just pretend.
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.
you have an email address to...
and a resume www.briangannon.com
and the Source RPMS.
http://stradlin.com/ssh
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
Yeah, phenomenal track record. Unless you're me. I've run Windows, Linux, and OpenBSD. Besides the usual Spyware, etc, my Windows box has never been exploited. My linux has never been exploitet.
My OpenBSD box? *sigh* I got bitten by the LAST ssh bug... which is why I'm so desperate to fix THIS one.
I will point out to people that this message "only one remote exploit in 7 years" said that before the last ssh bug. But then, I wasn't exploited until after they released 3.3, so you can possibly blame it no not upgrading.
I am unamerican, and proud of it!
They changed it from 0 to 1 when the last SSH vuln was disclosed. I see no reason that thye wouldn't do it this time. However, it's not afflicting OperBSD anyways...
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...
It could also be running out of inetd, in which case you won't see the process listed.
The vulnerability is fully exploitable under OpenBSD. I've just rooted my own OBSD firewall, and it actually hit the proper register faster than it did on my Gentoo desktop (not that that means anything).
:) But if only one does, then the damaga is done.
A post like this given a +5 is dangerous. I wonder how many OpenBSD users will read that, take his word for it, and not patch their systems. Probably not many
Everyone is entitled to their own opinion. It's just that yours is stupid.
I would guess you probably don't have to worry too much, but to be safe, rather than sorry, you should try to ascertain whether sshd is even running on your machine. If it's not, you have nothing to worry about. If it is, you should turn it off, and then upgrade to the latest version.
If you get yourself to a command line and type in
ps aux | grep sshdYou should see whether or not you have an ssh server running. If you do, you probably want to turn it off until you can get your system updated.
Hopefully someone who uses Debian or Lindows can tell you how to turn off sshd, I've never used either OS, so I'm not sure.
As a guess, look for something in your interface that talks about managing network servers, daemons, or services. You want to stop sshd (it might be listed as just ssh), and prevent it from starting up again when you reboot your machine.
If you're behind a firewall that filters port 22, you're probably fine either way since ssh listens on port 22, and the firewall is blocking access.
Hopefully someone else with more knowledge can fill in my gaps. In a lot of ways I'm still a GNU/Linux newbie, myself.
Good luck!
Ian
When did they start putting mySQL in the Linux kernel?
1f u c4n r34d th1s u r34lly n33d t0 g37 l41d
If you're running a webserver with ssh installed, then it's your responsibility to keep up with the latest patches, upgrades, etc. Of course with a 0-day exploit like this, it's going to be hard to fix quickly. I'd give the linux/bsd distro's a day to come up with a fix.
What you can do in the meantime, is set PermitRootLogin to No and firewall off ssh cept for a few hosts you login from.
"I keep looking in the want-ads under 'revolutionary' but there don't seem to be any listings.. "
Well, ssh is not multi-threaded and there is no way another process can write to that region(that would be classified as a kernel bug in any case) unless the buffer is in a shared memory, which is not. fatal() runs few cleanup handlers(which do not touch that buffer in any way) and exits with exit code 255, so fatal() is pretty much fatal.
I still have to find evidence of the exploit besides few mails with absolutely no technical detals. More and more I think this is some kind of hoax... and I can understand why everybody is so jumpy, afterall ssh is a crucial part of a "secure" box.
It appears that *nix systems now have an exploit
Yep, *nix systems have exploits, and an hour or two turnaround between discovery and a fix. I'd like to see Microsoft match that.
"Linux has no exploits that need patching"
People who actually know Linux would never claim that there are no known exploits, just that the time-to-fix is much shorter and that applying these fixes to running systems is usually much easier (in most distributions) than in a Windows system (ie no reboot required, one location for all necessary fixes, better software package management, etc)
I use Linux and BSD at home, but manage Windows machines at work (I have no decision making power, I'm just a grunt) and I must say that Windows management is a royal pain in the ass. We've had no problems with the recent Windows viruses and worms, but I do spend an inordinate amount of time applying patches, rebooting machines, and checking that the new patches did not wipe out the old ones. I don't think that it is unreasonable for Microsoft's customers to demand better patch/upgrade management, a single location for updates to both applications, servers, and the OS, and a better method for confirming that the files included in a patch contain the all of the required fixes (for that file) even if they came from different departments at microsoft.
Read, L
you can restrict access in your /etc/sshd_config (wherever you have it) like so until you can get the patched version, if you allow access from anywhere:
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).
-- http://frobnosticate.com
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.
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.
http://www.securityfocus.com/archive/1/337662/2003 -09-13/2003-09-19/0
No.
How to fix your RedHat box:
p m/SRPMS/op enssh-3.7p1-1.src.rpm
.rpm for your RedHat Linux version:
/usr/src/redhat/RPMS/i386/openssh-*.rpm
1.- Download the file openssh-3.7p1-1.src.rpm from any of the mirrors. For example:
ftp://ftp.easynet.be/openssh/portable/r
2.- Build an
# rpm --rebuild openssh-3.7p1-1.src.rpm
3.- Upgrade your OpenSSH packages:
# rpm -Fvh
4.- Re-start your sshd daemon:
service sshd restart
5. Profit!^H^H^H^H^H errr, that's it.
Peace.
OpenSSH buffer_append_space() Error May Let Remote Users Execute Arbitrary Code and OpenSSH "buffer_append_space()" Vulnerability
It appears that 3.7p1 is now in portage, so you can just emerge sync; emerge -u openssh
"The danger is not that a particular class is unfit to govern. Every class is unfit to govern." - Lord Acton
Just checked up2date and saw the RPMs there. Not sure if they fix the bug you mention, but at least they've patched the gaping security hole now.
-------
"Every artist is a cannibal, every poet is a thief."
Redhat has finally posted patched RPMS on their errata pages. Scroll down and select your release.
Redhat just released an advisory with links to updated RPMS: RHSA-2003-279
RedHat has fixes (source and binaries) on their FTP site and docs in the erratta pages.
l
https://rhn.redhat.com/errata/RHSA-2003-279.htm
For RedHat 7.1: openssh-3.1p1-9
For RedHat 7.2: openssh-3.1p1-10
For RedHat 7.3: openssh-3.1p1-10
For RedHat 8.0: openssh-3.4p1-5
For REdHat 9 : openssh-3.5p1-9
Good luck at getting to their FTP servers. Hopefully, the mirrors will get them soon.
It's on RedHat Network, so you can use up2date. I did "up2date -u", which updated openssh, openssh-askpass, openssh-askpass-gnome, openssh-clients and openssh-server. You still have to do step 5 above, restarting the ssh server.
Genebrew
The FreeBSD team has released a related Security Advisory and issued patches for affected FreeBSD versions as well as OpenSSH in the ports tree.
Corrected:
2003-09-16 16:24:02 UTC (RELENG_4)
2003-09-16 16:27:57 UTC (RELENG_5_1)
2003-09-16 17:34:32 UTC (RELENG_5_0)
2003-09-16 16:24:02 UTC (RELENG_4_8)
2003-09-16 16:45:16 UTC (RELENG_4_7)
2003-09-16 17:44:15 UTC (RELENG_4_6)
2003-09-16 17:45:23 UTC (RELENG_4_5)
2003-09-16 17:46:02 UTC (RELENG_4_4)
2003-09-16 17:46:37 UTC (RELENG_4_3)
2003-09-16 12:43:09 UTC (ports/security/openssh)
2003-09-16 12:43:10 UTC (ports/security/openssh-portable)
Ooops, I had totally forgotten about that old copy of the README file in the ftp archive. After it was pointed out to me in private mail, I've replaced it with the current README. /Niels (LSH author)
I've read the patch on SecurityFocus. It's very simple. It looks like there is a buffer that at some point needs to be reallocated to fit more data. However, if that reallocation would put the buffer over 32KB, then the reallocation is not performed. The bug was that the recorded size of the buffer would be increased, even if the allocation was not performed, but not reset back to the original size. The patch only increases the recorded buffer size if the buffer really is grown.
An exploit of this hole would have to find a way to trigger this buffer allocation, and get it to overflow 32KB. Since the allocation would not take place, but the recorded buffer size is still large, there would be an unallocated memory area that could be referenced by code that uses that buffer. One would need to use that to overwrite program code with exploit code.
A solution to the problem with music today
missing000's comment is quite correct, there's a mistake in my original post. Omit the DenyUsers line, it will override the AllowUsers line. Just use the AllowUsers line by itself.
Sorry.
AllowUsers you@your_ip_address
Remember, always test making a new ssh connection before logging out of your existing one, after restarting sshd.
-- http://frobnosticate.com
actually it's patched, and has been since ~ 11:00 EST. you're supposed to have security.d.o in your sources.list if you want security fixes.
-- bartman
http://readme.gzipped.org/~max/debian.html
Choose one of the sources.list lines depending on your CPU, insert it into your sources.list, update, upgrade, and you're safe.
I applied the patch from http://www.openssh.com/txt/buffer.adv to the original 3.6 Debian package from testing.
Sorry for the German text, I shared this repository of Debian Packages (unstable packages ported to Woody, compiled with gcc-3.2 and CPU optimizations) only with my German friends till now...
If using binaries/source from non-vendors weirds you out, you can also grab the RPMs for RH9, or the SRPMs for other releases (and presumeably other distros like SuSE, Mandrake, et al. as well) directly from the OpenBSD guys. The only US mirror which had them (as of this morning when I heard about the announcement) was ftp://ftp3.usa.openbsd.org/pub/OpenBSD/OpenSSH/por table/rpm/. I didn't look through the international mirrors, but I got pretty good speeds from across the country.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
For the record, the Red Hat packages released today to appear to address the bug you're referring to.
Good.
That means that Debian's default configuration for sshd is also secure.
// file: mice.h
#include "frickin_lasers.h"
iptables:
#!/bin/sh
insmod iptables
iptables -F INPUT
iptables -P INPUT ACCEPT
iptables -A INPUT -j ACCEPT -p tcp --destination-port 22 -s 1.2.3.4
iptables -A INPUT -j DROP -p tcp --destination-port 22
iptables -A INPUT -j DROP -p udp --destination-port 22
ipchains:
#!/bin/sh
insmod ipchains
ipchains -F input
ipchains -P input ACCEPT
ipchains -A input -j ACCEPT -p tcp --destination-port 22 -s 1.2.3.4
ipchains -A input -j DENY -p tcp --destination-port 22
ipchains -A input -j DENY -p udp --destination-port 22
[slackware-security] OpenSSH Security Advisory (SSA:2003-259-01)
w are-8. 1/patches/packages/openssh-3.7p1-i386-1.tgz
w are-9. 0/patches/packages/openssh-3.7p1-i386-1.tgz
s lackware-cu rrent/slackware/n/openssh-3.7p1-i486-1.tgz
/etc/rc.d/rc.sshd restart
Upgraded OpenSSH packages are available for Slackware 8.1, 9.0 and
- -current. These fix a buffer management error found in versions of
OpenSSH earlier than 3.7. The possibility exists that this error
could allow a remote exploit, so we recommend all sites running
OpenSSH upgrade to the new OpenSSH package immediately.
Here are the details from the Slackware 9.0 ChangeLog:
Tue Sep 16 11:13:05 PDT 2003
patches/packages/openssh-3.7p1-i386-1.tgz: Upgraded to openssh-3.7p1.
From the OpenSSH Security Advisory
(http://www.openssh.com/txt/buffer.adv):
"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."
(* Security fix *)
WHERE TO FIND THE NEW PACKAGES:
Updated package for Slackware 8.1:
ftp://ftp.slackware.com/pub/slackware/slack
Updated package for Slackware 9.0:
ftp://ftp.slackware.com/pub/slackware/slack
Updated package for Slackware -current:
ftp://ftp.slackware.com/pub/slackware/
MD5 SIGNATURES:
Slackware 8.1 package:
a86d410e47fe8ab4a8e9f04293a94093 openssh-3.7p1-i386-1.tgz
Slackware 9.0 package:
ca1d0b1e658c5391067f2a9cf11fc239 openssh-3.7p1-i386-1.tgz
Slackware -current package:
c58003eaaf4362c8475f0f5a77f2adbb openssh-3.7p1-i486-1.tgz
INSTALLATION INSTRUCTIONS:
(This procedure is safe to do while logged in through OpenSSH)
Upgrade using upgradepkg (as root):
# upgradepkg openssh-3.7p1-i386-1.tgz
Restart OpenSSH:
.
"The meek shall inherit the earth, the rest of us shall go to the stars." Isaac Asimov
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).
120 character sigs suck. Make it 250.
Get the new ones off Red Hat's site. They will say 3.1p1 (see here for why) instead of 3.7, but they do contain all current security fixes.
The problem was in buffer.[ch], which contains openssh's buffer structure and related functions. This is used in both the client and server. So, in short it is possible that both the client and server are vulnerable to exploits.
I read your post and thought to myself, "this was fixed before the exploit? I upgraded my system a few weeks ago, I wonder if I got 3.7?"
Instead of going to figure out when 3.7 was released (could have been today for all I know, I didn't read everything this article linked to), I went looking for how to track my emerges and I found:
this.
Hope this informs someone else.
Cheers
~Dalcius
Rome wasn't burnt in a day.