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:\>
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
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
... can be found here http://archives.neohapsis.com/archives/fulldisclo
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
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
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.
This is the README from 1998, talking about a beta version of lsh. Don't let age-old doumentation fool you.
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.
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
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 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
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.
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
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)
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
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