Forgot your password?
typodupeerror
Security

New ssh Exploit in the Wild 754

Posted by CmdrTaco
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

Comments Filter:
  • Uh oh (Score:5, Funny)

    by Anonymous Coward on Tuesday September 16, 2003 @11:07AM (#6975461)
    Best patch and upgr..&*[NO CARRIER]
  • Questions. (Score:5, Interesting)

    by grub (11606) <slashdot@grub.net> on Tuesday September 16, 2003 @11:09AM (#6975484) Homepage Journal

    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.
  • CRAP! (Score:3, Informative)

    by code shady (637051) on Tuesday September 16, 2003 @11:10AM (#6975494) Homepage
    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.
  • by Morologous (201459) * on Tuesday September 16, 2003 @11:10AM (#6975500)
    Posting this to slashdot is actually a public service, as the exploit description will be /.'d and unable to effectively be disseminated to the bad actors.
  • Patch (Score:5, Informative)

    by Karamchand (607798) on Tuesday September 16, 2003 @11:11AM (#6975502)
    Link to a patch [theaimsgroup.com].
  • Full Disclosure (Score:4, Informative)

    by Anonymous Coward on Tuesday September 16, 2003 @11:11AM (#6975505)
    [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.

    • by JoeBuck (7947) on Tuesday September 16, 2003 @12:35PM (#6976568) Homepage

      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)

      by bahamat (187909) on Tuesday September 16, 2003 @01:05PM (#6976938) Homepage
      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.
  • Telnet (Score:5, Funny)

    by Henry V .009 (518000) on Tuesday September 16, 2003 @11:11AM (#6975506) Journal
    Thank god I'm using something secure like Telnet instead.
  • by ferratus (244145) * on Tuesday September 16, 2003 @11:11AM (#6975513) Homepage
    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 (Score:4, Interesting)

    by secolactico (519805) on Tuesday September 16, 2003 @11:13AM (#6975529) Journal
    Won't having the sshd wrapped (/etc/hosts.allow, /etc/hosts.deny) help offset the damage somewhat?
    • Re:Wrapping defense (Score:3, Informative)

      by Minna Kirai (624281)
      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 th
    • by TomatoMan (93630) on Tuesday September 16, 2003 @01:00PM (#6976886) Homepage Journal
      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).
      • That string won't work. (At least under RH9).

        If you want to block all users but your list of allowed users, just use:

        AllowUsers user1@users_ip_address user2@users_ip_address ... # To allow only by IP address

        or AllowUsers user1 user2 ... # To allow from any IP

        That DenyUsers string blocks your list of allowd no matter where you put it.
      • by TomatoMan (93630) on Tuesday September 16, 2003 @02:48PM (#6978031) Homepage Journal
        missing000's comment [slashdot.org] 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.
      • by maiden_taiwan (516943) on Tuesday September 16, 2003 @04:11PM (#6978804)
        "AllowUsers you@your_ip_address" doesn't do what you might think it does. As written, it looks like it says something about a remote user. It doesn't.

        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]. :-)

  • by Oestergaard (3005) on Tuesday September 16, 2003 @11:15AM (#6975550) Homepage
    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)!
    • Update for debian (Score:5, Informative)

      by Oestergaard (3005) on Tuesday September 16, 2003 @11:23AM (#6975640) Homepage
      An updated ssh package just hit the Debian security mirrors.

      For anyone running debian stable:
      apt-get update
      apt-get upgrade

      • by bartman (9863) on Tuesday September 16, 2003 @11:36AM (#6975782) Homepage Journal
        Debian is absolutely amazing.

        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)

      by jehreg (120485) on Tuesday September 16, 2003 @11:37AM (#6975785) Homepage
      Just go to your net-misc/openssh directory:
      • 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
  • guess who (Score:5, Funny)

    by dwakeman (171962) on Tuesday September 16, 2003 @11:15AM (#6975555) Homepage
    Damn trinity and her sshnuke...
  • by johnny1111_23 (705700) on Tuesday September 16, 2003 @11:15AM (#6975556)
    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.

    • by Abcd1234 (188840) on Tuesday September 16, 2003 @11:24AM (#6975659) Homepage
      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").
    • 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?


      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 "/et
    • WOW!! (Score:5, Funny)

      by narratorDan (137402) <narratordan@gmail.com> on Tuesday September 16, 2003 @12:03PM (#6976142)
      I just read all these replies (about 15 right now) and all of them are nice and respectfull of the fact that this guy is a newbie!
      I must be on the wrong site.

      NarratorDan
  • by LittleLebowskiUrbanA (619114) on Tuesday September 16, 2003 @11:17AM (#6975573) Homepage Journal
    This has already been posted and a fix (upgrade to 3.7) has been posted to www.deadly.org
  • by RedHat Rocky (94208) on Tuesday September 16, 2003 @11:17AM (#6975574)

    Great, now maybe Redhat will fix their damn openssh RPMs that they fubarred [redhat.com] with their last patch!

    • by opkool (231966) on Tuesday September 16, 2003 @01:29PM (#6977219) Homepage
      How to fix your RedHat box:

      1.- Download the file openssh-3.7p1-1.src.rpm from any of the mirrors. For example:
      ftp://ftp.easynet.be/openssh/portable/rp m/SRPMS/op enssh-3.7p1-1.src.rpm

      2.- Build an .rpm for your RedHat Linux version:

      # rpm --rebuild openssh-3.7p1-1.src.rpm

      3.- Upgrade your OpenSSH packages:

      # rpm -Fvh /usr/src/redhat/RPMS/i386/openssh-*.rpm

      4.- Re-start your sshd daemon:

      service sshd restart

      5. Profit!^H^H^H^H^H errr, that's it.

      Peace.
  • by teamhasnoi (554944) * <{moc.oohay} {ta} {ionsahmaet}> on Tuesday September 16, 2003 @11:21AM (#6975615) Homepage Journal
    I was at the local library, and some kids were on a computer, talking loudly. They seemed to be rather excited about something.

    A librarian peeked around the corner to see where the noise was coming from, then put her finger to her lips and said, "Ssh!"

    The kids ignored her and kept talking, completely and utterly exploiting the hole, and circumventing the 'Ssh'!

    Never was I so frightened.

  • by Stephen Williams (23750) on Tuesday September 16, 2003 @11:25AM (#6975670) Journal
    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
  • by Doodhwala (13342) on Tuesday September 16, 2003 @11:27AM (#6975695) Homepage
  • by Tuck (41529) on Tuesday September 16, 2003 @11:37AM (#6975794) Homepage
    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
  • Right... (Score:5, Insightful)

    by guinsu (198732) on Tuesday September 16, 2003 @11:38AM (#6975799)
    As opposed to the lengths people will go to to damage Microsoft? But that's ok, right?
  • by next_permutation (627092) on Tuesday September 16, 2003 @11:39AM (#6975817) Homepage
    An OpenSSH Security Advisory [openssh.com] was just posted about this.
  • Coincidence, Or... (Score:5, Interesting)

    by 4of12 (97621) on Tuesday September 16, 2003 @11:40AM (#6975821) Homepage Journal

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

    • by s.d. (33767)
      Why the conspiracy theory? Why isn't it possible that the bug had been identified, the developers decided it was enough of a reason to push a new release, and when the new release is pushed, with the reason being b/c of a bug that may or may not be exploitable. Then unsubstantiated rumors of exploits start floating around b/c of this.

      There isn't a grand conspiracy. It's just how people work. I person says something like, "So I heared that there is the possibility of an exploit due to a bug in OpenSSH t
  • Updating for Gentoo (Score:5, Informative)

    by Synn (6288) on Tuesday September 16, 2003 @11:46AM (#6975881)
    If you don't want to wait for the official ebuild:

    cd /usr/portage/net-misc/openssh/
    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
    • by Aardpig (622459) on Tuesday September 16, 2003 @01:22PM (#6977149)

      If you don't want to wait for the official ebuild:

      cd /usr/portage/net-misc/openssh/
      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

      This will fail if you have kerberos support USE'd, with an error involving gssapi.h not being found. The solution? Replace the final line with this:

      USE="-kerberos" emerge openssh-3.7_p1.ebuild

  • by kakos (610660) on Tuesday September 16, 2003 @11:53AM (#6975975)
    It seems to me that a package that goes through code security audits regularly and is actually finished is infinitely more secure than an incomplete package?

    Why are there people suggesting to go from a secure package to an insecure one?
  • by pollock (453937) on Tuesday September 16, 2003 @02:13PM (#6977715) Homepage
    Redhat has finally posted patched RPMS on their errata [redhat.com] pages. Scroll down and select your release.
  • by gunnarE (251760) on Tuesday September 16, 2003 @02:14PM (#6977721)
    Redhat just released an advisory with links to updated RPMS: RHSA-2003-279 [redhat.com]
  • by dnaumov (453672) on Tuesday September 16, 2003 @02:35PM (#6977907)
    The FreeBSD team has released a related Security Advisory [freebsd.org] 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)
  • by getnuked (595037) on Tuesday September 16, 2003 @04:32PM (#6979055)
    If you can't get to an update for your distro, here is a quick and dirty script for both iptables and ipchains based machines to limit SSH access to only specific IPs (replace 1.2.3.4 with the address you want to connect from, add more lines to add more hosts) - of course these only apply to Linux based machines with either iptables or ipchains in the kernel or available as modules:

    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

No line available at 300 baud.

Working...