OpenBSD Journal

OpenSSH 3.7 released

Contributed by jose on from the fixing-bugs dept.

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 https://https.openbsd.org/cgi-bin/order and for European orders, use https://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.

Additional changes below.

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 the source distribution.
    • On platforms that support it, portable OpenSSH now honors the UMASK, PATH and SUPATH attributes set in /etc/default/login.
    • Deny access to locked accounts, regardless of authentication method in use.

Checksums:

  • MD5 (openssh-3.7.tgz) = 86864ecc276c5f75b06d4872a553fa70
  • MD5 (openssh-3.7p1.tar.gz) = 77662801ba2a9cadc0ac10054bc6cb37

Reporting Bugs:

  • please read http://www.openssh.com/report.html and http://bugzilla.mindrot.org/
OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller, Ben Lindstrom, Darren Tucker and Tim Rice.

(Comments are closed)


Comments
  1. By Anonymous Coward () on

    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.

    You keep using that word. I do not think it means what you think it means. I'm not sure why they've bothered making that comment, anyway, Gobbles will have proof-of-concept code available within a week.

    Comments
    1. By Anonymous Coward () on

      Props for the Princess Bride reference!

    2. By Anonymous Coward () on

      I apologize for my comment, as I've since learned there's a remote exploit already in the wild. My bad.

  2. By nbfghfh () on

    Ist euch auch schon aufgefallen das es immer eine neue OpenSSH-Version gibt nach dem Bekanntwerden eines Sicherheitslochs?

    Ist ja auch positiv zu sehen...

    Comments
    1. By Anonymous Coward () on

      Translation anyone?

      Comments
      1. By Steve S. () on

        You been noticeable is it a new open H version already always gives after becoming known a safety hole? Is to be seen also positive...

        Trusty Babelfish

        Comments
        1. By Anonymous Coward () on

          Ah babelfish =| Could it be this means: "You may have noticed that a new OpenSSH version is always released right after (the previous version) has become exploitable?" ??

  3. By rete () on

    another remote-compromise in the openbsd default install?

    Comments
    1. By Anonymous Coward () on

      Yes, it is remotely, root-level exploitable on OpenBSD with PrivSep enabled.

      Comments
      1. By X () on

        does someone have the sourcecode of the exploit ?
        or a tcpdump data

      2. By sanda () on

        :-(

        shit happends...

        BTW.. are you really sure about that fucking fact?

      3. By Justin () on

        not according to this .

      4. By Anonymous Coward () on

        Hey 208.252.48.163,

        I've seen no evidence that it is exploitable on OpenBSD, I've seen no evidence that there's an exploit available or seen no one that's willing to post any code substantiating it, how about we all just go one and be good little sys admins and patch our systems, against a *POTENTIAL* vulnerability. As all postings I've seen place heavy emphasis on the word *POTENTIAL*.

        I'm sure someone will write an 'sploit of it and yes it may in fact affect OpenBSD, but as of yet, no one's provided any proof what so ever that it is exploitable on OpenBSD, merely that a buffer overflow exists which could *POTENTIALLY* lead to an exploit.

        In other words, shut up or put up!

      5. By djm () on

        Please send your exploit to openssh@openbsd.org and we will update our advisory to mention that an exploit exists.

        Don't have one? Stop talking like you do.

        Comments
        1. By Anonymous Coward () on

          Riiiiight. *rolls eyes*

  4. By Anonymous Coward () on

    I've been over the diff myself and with a friend and we both agree that the worst thing that could happen is a denial of service caused by memory corruption since the area after the buffer is overwritten with nulls should fatal() be called.

    In other words: it is impossible to exploit this to gain remote root access.

    Now, would someone who has actually seen this magical "exploit" describe what method it uses? I'm pretty sure if such an exploit does exist, then it uses another vulnerability, not this one, to break in.

    Now, show us the exploit.

    Comments
    1. By rankor_indeustries () on

      Aye, I looked it over as well and the DoS seems reasonable but an exploit does not. Judging by the "Anonymous Cowards" that post, who seem to have loud voices, they are just trolls doing what trolls do best... stink up the room.

    2. By Anonymous Coward () on

      The fact that you and your friend are incompetent is not our problem. Keep fooling yourself. How about you use your real name on here so there will be a record of your stupidity when the exploit leaks?

      Comments
      1. By Nate () on

        And yet you do not use your name to insult someone, funny that. Now it would become amusing if there is no valid exploit and this whole thing is just another coding problem that has been fixed and a warning given in case it could be exploited.

        I shouldn't feed you like this, but who can resist?

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]