OpenBSD Journal

Portable OpenSSH 3.7.1p2 released

Contributed by jose on from the portable-security dept.

(Pasting from Damien Miller's announcement.) Portable OpenSSH 3.7.1p2 has just been released. It will be available from the mirrors listed at http://www.openssh.com/portable.html shortly.

Note that this is a release to address issues in the portable version only. The items mentioned below do not affect the OpenBSD version.

Security Changes

Portable OpenSSH version 3.7p1 and 3.7.1p1 contain multiple vulnerabilities in the new PAM authentication code. At least one of these bugs is remotely exploitable (under a non-standard configuration, with privsep disabled).

OpenSSH 3.7.1p2 fixes these bugs. Please note that these bugs do not exist in OpenBSD's releases of OpenSSH.

Changes since OpenSSH 3.7.1p1

  • This release disables PAM by default. To enable it, set "UsePAM yes" in sshd_config. Due to complexity, inconsistencies in the specification and differences between vendors' PAM implementations we recommend that PAM be left disabled in sshd_config unless there is a need for its use. Sites using only public key or simple password authentication usually have little need to enable PAM support.
  • This release now requires zlib 1.1.4 to build correctly. Previous versions have security problems.
  • Fix compilation for versions of OpenSSL before 0.9.6. Some cipher modes are not supported for older OpenSSL versions.
  • Fix compilation problems on systems with a missing or lacking inet_ntoa() function.
  • Workaround problems related to unimplemented or broken setresuid/setreuid functions on several platforms.
  • Fix compilation on older OpenBSD systems.
  • Fix handling of password-less authentication (PermitEmptyPasswords=yes) that has not worked since the 3.7p1 release.
Checksums

MD5 (openssh-3.7.1p2.tar.gz) = 61cf5b059938718308836d00f6764a94

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 gwyllion () on

    Portable OpenSSH Security Advisory: http://www.openssh.com/txt/sshpam.adv

  2. By Anonymous Coward () on

    Now let me guess: Last nights update to Mac OS X 10.2.8 does NOT include that last issues.

    I think it is time to prepare for some quick update to this on OS X without waiting for apple's software testing.

    Comments

    1. By Anonymous Coward () on

      Mac OS X should be fine, AFAIK it doesn't use PAM at all (being BSD based and all).

      Comments

      1. By Anonymous Coward () on

        % uname -sr
        Darwin 6.8
        % man pam

    2. By gwyllion () on

      MacOS X 10.2.8 includes a patched version on OpenSSH 3.4.

      This bugs were introduced with the new PAM code from FreeBSD (only 3.7 and 3.7.1 have this new code).

  3. By Sacha () on

    As usual PAM does more bad then good.

  4. By Anonymous Coward () on

    I tried this on a couple boxes with mixed results. On a Mandrake 9.1 box (with all updates), I wiped out my /etc/pam.d/sshd file, and installed as I've done a million times, except with ./configure instead of ./configure --with-pam, and it worked perfectly.

    Trying to do the same thing on a Mandrake 9.0 box (with all updates) refused to let me log in. The sshd config files were the same, as was the means of installation. I have gone back to using PAM with this new version and it works fine. What would cause authentication without PAM to work on some systems and not others?

    Comments

    1. By Anonymous Coward () on

      To answer my own question, the 9.0 box worked when compiled with the --with-md5-passwords option. I don't know why the 9.1 box worked correctly without it, because ./configure definitely listed MD5 passwords as a "no," but this isn't the place to ask.

      Comments

      1. By djm () on

        Some OS vendors do the right thing and ship a crypt() function in libc which matches the password encrpytion scheme in use, others don't.

  5. By Anonymous Coward () on

    During the last major OpenSSH hole, I posted a suggestion that maybe it's time to not use languages like C (which have buffers, which manipulate memory directly, and which basically rely on the programmer to not make mistakes to protect memory) for services which handle hostile connections (ie, connections to the open Internet). I got flamed by people making generic criticisms like "Java sucks. Learn how to program." to more specific criticisms, like "Java is too slow."

    For hobbiests or home users, hardware costs matter a lot, but for business users, the damage (cost) of a security breach far exceeds their total hardware budgets. How much would it "cost" Yahoo to be compromised? Spending some more money to use safer tools, like Java, is a bargain for a business user.

    I'm convinced at this point that ALL network services, from ping to ssh, should be written in languages which have the following characteristics:

    1. No direct access to memory.

    2. Program integrity checks before executing (like the bytecode verifier).

    3. A virtual machine runtime environment.

    4. Designed from the beginning for containment and isolation.

    The only language that I know meets these needs is Java. That said, I know nothing about Ruby or Python and probably others that may also meet these requirements.

    When I have time to devote to this I'm going to start my 100% Java network server suite, going from small (ping) all the way to higher-level protocols like ssh or nfs. Fortunately some of the work (such as http and dns) has already been done.

    Comments?

    Comments

    1. By Mike S () on www.nedyah.org

      I was with you right up until the part about the java.

      I would like to hear an explanation as to why all this stuff is written in c. I am sure the people doing it have their reasons, though.

      I would think that c++ could do the job a little better. If you encapsulate your strings and buffers in safe classes, you trade a little speed for having a common string class that you know will not overflow.

      But my impression is that when the chips are down, you really don't have the luxury of trading that much speed (and efficiency when its done right) for security.

      So I'm curious to hear what people think.

      Comments

      1. By Anonymous Coward () on

        " I would like to hear an explanation as to why all this stuff is written in c."

        It is a portable high-level assembler


        "I would think that c++ could do the job a little better."

        as they say, it is easy to shoot yourself in the foot in C

        with C++ you can blow your whole leg off


        "encapsulate your strings and buffers in safe classes"

        you mean like the safe string C libs for most OSs based on OpenBSD's ???

    2. By Sacha () on

      Religiously I'll have to disagree on the java bit here.

      Allthough allsorts of solutions are available, the OpenSSH team will prolly have their reasons to write their code in C.

      Rewriting the code would take up more time (of learning a new language and) starting from scratch.

      But in the end, nothing is holding you back to chroot sshd ;-)

    3. By Nate () on

      It's not the language you use that will magically make your programs secure, it's the ability of the programmer. C and C++ are used for systems level programming because of their speed. If the programmers focused on writing secure software instead of writing software to meet deadlines then we wouldn't have as many problems. Java can be as insecure or more insecure then C if it is coded incorrectly. If you are really interested in redoing these utilities I would suggest you check out "Secure Coding" it's an O'Reilly book.

      ~Nate

    4. By Anonymous Coward () on

      what about lua? it's small, fast (for a scripting language), and integrates easily with c if needed.

    5. By tedu () on

      java offers no more guarantee that your code is algorithmically or logically correct than any other language.

      second question: how many (and which) platforms do you intend to support?

      Comments

      1. By MotleyFool () motelydawg@dung.org on mailto:motelydawg@dung.org

        Hmmm, I 2nd the question. How many platforms do you want to support. C is pretty ubiquitous.

    6. By djm () on

      Please get on with it.

      It is annoying to see armchair experts making recommendations to completely rewrite every network app we have used without putting the work in to do it themselves. Nevermind the fact that one can make errors just as easily in any language (though some are easier to audit) and nevermind the long history of magical languages and programming ideologies which promise to solve all software problems.

      http://www-inst.eecs.berkeley.edu/~maratb/readings/NoSilverBullet.html

    7. By Anonymous Coward () on

      >3. A virtual machine runtime environment.

      Why? This is _the_ performance killer.
      I believe a virtual machine system is a dead-end
      for deploying real apps. A "naive" native code
      generator is not really any harder to write, and
      native code from a naive code generator will beat
      a sophisticated VM any day. Especially on modern
      processors where jumps are expensive. A VM
      implementation spends most of its time jumping
      around inside the interpreter. JIT? Yes, but
      then you might as well write a native back-end,
      and the resulting whole is likely to be simpler
      and more reliable.

      You CAN implement a safe language with a
      native code compiler. Done decades ago, for example
      in the "Wirth languages" (Pascal, Modula-2, Oberon).

      With the native back-end, you can have all kinds
      of run-time checks always activated, and the
      compiler can then omit most of the unnecessary ones
      (detected using dataflow analysis) during code
      generation. I think an IBM researcher published a
      paper on this already some 25 years ago - ours is
      the industry that never learns from the past... :-(

    8. By Michael () on

      I encourage you to write the Java network suite. I think nfs might prove to be a bit clunky, though. If it makes sense and works well, people will use it. When you have a release or a project page, let us know.

      --Michael

    9. By Me () what? get another virus@work on mailto:what? get another virus@work

      For hobbiests or home users, As in: Hobby, Hobbier, Hobbiest? Hobbyist, dick! Frickin' Dr Dobbs wankers survive to this day!

    10. By grey () on

      Ummm, why don't you focus your efforts on porting the Java SDK etc to OpenBSD before you complain about why the project doesn't use the language. Not to say that it's a bad language, but it really doesn't seem like it's a viable options for OpenBSD right now, unless you expect them to start using gcj or something.

      Comments

      1. By Kurt () on http://www.openbsd.org/cgi-bin/cvsweb/ports/devel/

        There are several ports of the JDK for OpenBSD:

        native (green threads, nojit)
        devel/jdk/1.2

        linux emulation (green threads, nojit)
        devel/jdk/1.2-blackdown
        devel/jdk/1.3-linux

        However more work is needed to get native threads and jit working. Also, I believe Niklas@ has a port of native 1.3 completed or nearly so.

        There is a low volume mailing list for those interested in Java on OpenBSD:

        http://codemonkey.net/mailman/listinfo/openbsd-java

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