Results 1 to 10 of 10

Thread: OpenSSH 3.3

  1. #1
    Aaron_Adams
    Guest

    OpenSSH 3.3

    On June 21 OpenSSH 3.3 was released. The key emphasis for this release was the compatability of privelage separation on linux and solaris operation systems. This feature allows a small portion of the program to be run as root, and the remainder to be forked to a chroot-jail. Having these settings in effect minimize the chances of exploitation of a system.

    Recently Theo De Raadt posted to numerous mailing lists explaining that the OpenSSH team, in collaboration with ISS, will be releasing information on a security bug in OpenSSH. This bug is not fixed by the latest release of OpenSSH and can only be avoided by implementing privelage separation.

    It is important that you upgrade OpenSSH as soon as possible. Fortunately Privelage separation is enabled by default. To verify check for the following in /usr/local/etc/sshd_config
    #UsePrivelageSeparation yes
    Although the option is commented it is still in effect by default. Default configuration settings are commented in OpenSSH configuration files.

    If you've upgraded your OpenSSH to version 3.3 and you don't see UsePrivelageSepration, it is due to an sshd_config file already being present prior to updating. To remedy this problem, back up or remove your old sshd_config and make install again.

    This security bug will most assuredly affect you, so it is important that you upgrade your system accordingly.

  2. #2
    JimH
    Guest

    Re:OpenSSH 3.3

    Sounds like we can expect a flood of upgrades to OpenSSH from the major Linux distro's over the next few days.

    Jim H

  3. #3
    mugs
    Guest

    Re:OpenSSH 3.3

    What exactly is OpenSSH and what do I need to do...I have Suse 8.0

    Thanks.

  4. #4
    Aaron_Adams
    Guest

    Re:OpenSSH 3.3

    OpenSSH is a secure shell program. It's like telnet or rlogin, but all sessions are encrypted. It can also be used for ftp like services with sftp.

    Chances are Suse 8.0 comes with OpenSSH by default. You can check using the command:
    $ whereis ssh
    To check the version:
    $ ssh -v
    To see if it's running:
    $ netstat -a | grep 22
    $ ps -aux | grep sshd
    If it is running and you want to shut it down:
    $ killall sshd

    If you don't use ssh to remotely login into your computer, I would recommend shutting it down and disabling it on startup. This can be accomplished by either modifying your xinetd files or your rc files. I'm not sure where it is controlled in Suse 8.0.

  5. #5
    JimH
    Guest

    Re:OpenSSH 3.3

    This was posted on the Red Hat mailing lists in response to an inquiry as to when Red Hat would be releasing an update.

    Just a note on this, please note that to this point, all that has been released is an assurance that the exploit doesn't affect openssh when using PrivSep . . . no one has produced the exploit . . . no one has shown proof that a PrivSep setup isn't vunerable.

    So, not saying that this is or isn't the case, just wanted to make people aware that there's no proof that what has been published about PrivSep is really true. To that note, we will have fixed packages out as soon as we are sure that our packages are fixed :-) Oddly enough, this is the way that Red Hat always releasing updates.

    - jkt

    --
    --*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*
    Jay Turner, QA Manager Red Hat, Inc.


    So I guess they have yet to verify this bug report.

    Jim H

  6. #6
    Aaron_Adams
    Guest

    Re:OpenSSH 3.3

    It's probably good that they aren't jumping the gun. Although, somehow I doubt one of the head develepors of the program would be spreading false rumours. Theo may be considered an ass by some, but I don't think he is that bad!

  7. #7
    JimH
    Guest

    Re:OpenSSH 3.3

    More info on this.


    ISS X-Force recommends that system administrators disable unused OpenSSH authentication mechanisms. Administrators can remove this vulnerability by disabling the Challenge-Response authentication parameter within the OpenSSH daemon configuration file. This filename and path is typically: /etc/ssh/sshd_config. To disable this parameter, locate the corresponding line and change it to the line below:

    ChallengeResponseAuthentication no

    The "sshd" process must be restarted for this change to take effect. This workaround will permanently remove the vulnerability. X-Force recommends that administrators upgrade to OpenSSH version 3.4 immediately. This version implements privilege separation, contains a patch to block this vulnerability, and contains many additional pro-active security fixes. Privilege separation was designed to limit
    exposure to known and unknown vulnerabilities. Visit
    http://www.openssh.com for more information.

    -----


    Red Hat has not yet announced whether or not this exploit is present in their OpenSSH release. However, ChallengeResponseAuthentication defaults to yes on my 7.3 box.

    But this was posted by another Red Hat user.


    Reviewing the announcement, I wonder if this affects Red Hat's OpenSSH
    at all... The output of the configure process indicates positively that
    the affected BSD Auth and S/KEY authentication mechanisms are not
    available

    <snippage.....>

    RHL OpenSSH build:
    OpenSSH has been configured with the following options:
    User binaries: /usr/bin
    System binaries: /usr/sbin
    Configuration files: /etc/ssh
    Askpass program: /usr/libexec/openssh/ssh-askpass
    Manual pages: /usr/share/man/manX
    PID file: /var/run
    sshd default user PATH: /usr/bin:/bin:/usr/sbin:/sbin
    Manpage format: doc
    PAM support: yes
    KerberosIV support: no
    Smartcard support: no
    AFS support: no
    S/KEY support: no
    TCP Wrappers support: yes
    MD5 password support: no
    IP address in $DISPLAY hack: no
    Use IPv4 by default hack: no
    Translate v4 in v6 hack: yes
    BSD Auth support: no
    Random number source: OpenSSL internal ONLY


    Jim H

  8. #8
    JimH
    Guest

    Re:OpenSSH 3.3

    OK, from reading this advisory and the options Red Hat uses to compile OpenSSH it looks to me like Red Hat IS NOT vulnerable.

    OpenSSH supports the SKEY and BSD_AUTH authentication options. These are compile-time options. At least one of these options must be enabled
    before the OpenSSH binaries are compiled for the vulnerable condition to
    be present.


    As mentioned in my previous post these options are not enabled at compile time by Red Hat.

    http://online.securityfocus.com/arch...3/2002-06-29/0

    Jim H

  9. #9
    Aaron_Adams
    Guest

    Re:OpenSSH 3.3

    When I ./configure OpenSSH 3.3 on my box (slackware) it says that S/key and BSD Auth support are not enabled. Although the values are still set to yes in the default sshd_config. I think the problem is more prominent on OpenBSD and FreeBSD releases, as the advisories say.

    It's obviously still best to upgrade to 3.4 as it fixes other bugs as well.

  10. #10
    Spot
    Guest

    Re:OpenSSH 3.3

    Appendix A. - Vendor Information (coutesy of CERT - the bastids :P)


    This appendix contains information provided by vendors for this
    advisory. As vendors report new information to the CERT/CC, we will
    update this section and note the changes in our revision history. If a
    particular vendor is not listed below, we have not received their
    comments.


    Compaq Computer Corporation


    SOURCE: Compaq Computer Corporation, a wholly-owned subsidiary of Hewlett-Packard Company and Hewlett-Packard Company HP Services.
    Software Security Response Team


    x-ref:SSRT2263


    At the time of writing this document, Compaq is currently
    investigating the potential impact to HP Tru64 UNIX, commercial
    version of SSH for V5.1a.


    As further information becomes available notice will be provided of
    the completion/availability of any necessary patches through standard
    product and security bulletin announcements and be available from your
    normal HP Services support channel.


    Caldera


    Caldera OpenLinux OpenSSH has neither the S/KEY nor BSD Auth features
    compiled in, so it is not vulnerable to the Challenge/Response
    vulnerability. We do have the ChallengeResponseAuthentication option
    on by default, however, so to be safe, we recommend that the option be
    disabled in the sshd_config file.


    In addition, the sshd_config PAMAuthenticationViaKbdInt option is off
    by default, so OpenLinux is not vulnerable to the other alleged
    vulnerability in a default configuration, either. However, Caldera
    recommends that this option be disabled if it has been enabled by the
    system administrator.


    Cray, Inc.


    Cray, Inc. has found the OpenSSH released in Cray Open Software 3.0 to
    be vulnerable. Please see Field Notice 5105 and spr 722588 for fix
    information.


    Debian


    Debian 2.2 (the current stable release) is not affected by these
    problems. The current versions of our "testing" distribution, to
    become Debian 3.0, and our "unstable" distribution, are both affected
    by default.


    We recommend that users be certain that both:


    ChallengeResponseAuthentication no


    and


    PAMAuthenticationViaKbdInt no


    are present and uncommented in /etc/ssh/sshd_config (and that the
    server is restarted). Also, we recommend the use of version 3.3p1, now
    available from security.debian.org (DSA-134). Stable users do not need
    to upgrade and may wish to wait until the packages have received
    better testing.


    We intend to provide 3.4p1 packages in the near future.


    Engarde


    Guardian Digital ships OpenSSH in all versions of EnGarde Secure
    Linux. Version 3.3p1 was introduced by ESA-20020625-015 on June 25,
    2002. This update introduces privilege separation. All users are
    strongly urged to upgrade to this version as soon as possible.


    An upgrade to version 3.4p1 (which properly fixes the bugs) will be
    made available sometime in the next few days.


    Hewlett-Packard Company


    Hewlett-Packard provides a version of SSH: HP-UX Secure Shell
    (T1471AA) for HP-UX versions 11.00 and 11i. We are investigating to
    determine whether this product is vulnerable.


    IBM Corporation


    IBM's AIX operating system does not ship with OpenSSH; however,
    OpenSSH is available for installation on AIX via the Linux Affinity
    Toolkit. The version included on the CD containing the Toolkit is
    vulnerable to the latest discovered vulnerability discussed here as is
    the version of OpenSSH available for downloading from the IBM Linux
    Affinity website. Anyone running this version is advised to follow the
    recommendations above to limit their vulnerability.


    We working with the changes for version 3.4 and will have a new
    package availble for download as soon as possible. When available the
    new packages can be downloaded from:


    http://www6.software.ibm.com/dl/aixtbx/aixtbx-p


    This site contains Linux Affinity applications containing
    cryptographic algorithms, and new users of this site are asked to
    register first.


    Lotus


    Lotus products are not vulnerable to this problem.


    Mandrake Software


    MandrakeSoft released OpenSSH 3.3p1 in updates Monday night to
    mitigate this vulnerability. Updates to OpenSSH 3.4p1 will be
    available for download later this week.


    Microsoft Corporation


    Microsoft products are not affected by the issues detailed in this
    advisory.


    Network Appliance


    NetApp systems are not vulnerable to this problem.


    OpenBSD


    See http://www.openbsd.org/errata.html#sshd


    OpenSSH


    See http://www.openssh.com/txt/preauth.adv


    Process Software


    MultiNet, TCPware, and SSH for OpenVMS are not affected by the
    problems outlined in this advisory.


    RedHat Inc.


    Red Hat Linux versions 7, 7.1, 7.2 and 7.3 as well as Red Hat Linux
    Advanced Server version 2.1 ship with OpenSSH. The Red Hat Linux
    OpenSSH packages were not compiled with either BSD_AUTH or SKEY
    enabled, therefore in order to be vulnerable to this issue a user
    would need to have enabled the configuration option
    "PAMAuthenticationViaKbdInt" in their sshd configuration file (the
    default is disabled).


    We are continuing to investigate this vulnerability and will release
    updated packages where appropriate.


    SGI


    At this time, SGI does not ship OpenSSH as a part of IRIX.


    The OpenSSH privilege separation code mostly works with IRIX, but it
    uses a flag to mmap that isn't in IRIX (MAP_ANON) for compression so
    you can't have both on at the same time. IRIX doesn't ship with PAM so
    a lot of the PAM issues aren't issues for us.

Similar Threads

  1. OpenSSH
    By beezlebubsbum in forum Linux - General Topics
    Replies: 7
    Last Post: 11-20-2004, 03:03 AM
  2. OpenSSH Problem
    By infinite_root in forum Linux - Hardware, Networking & Security
    Replies: 3
    Last Post: 03-19-2004, 08:54 AM
  3. OpenSSH 3.5 Released
    By Aaron_Adams in forum Linux - Software, Applications & Programming
    Replies: 0
    Last Post: 10-16-2002, 01:54 PM
  4. OpenSSH source trojan
    By Compunuts in forum Linux - Software, Applications & Programming
    Replies: 15
    Last Post: 08-05-2002, 01:29 AM
  5. openssh for rh 6.2
    By elovkoff in forum Linux - General Topics
    Replies: 4
    Last Post: 06-19-2002, 01:24 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •