Re: [Fwd: ISS Advisory: OpenSSH Remote Challenge Vulnerability]
I am a bit worried about the ssh advisories, not the actual package
itself (well, that too) but the way it was handled -- the openssh team
issued new versions of a package and a security advisory asking
everyone to update to the new package, Debian and others jumped on it
and sent the new version out. The possibility of distributing a wide
scale worm or virus using this approach is obvious.
This seems to relate to the discussion about security advisories
violating the social contract as well. If the social contract was
followed, there wouldn't be a security advisories based on information
that the community cannot verify (in this case, I understand that not
even the security officers could verify if the ssh package was
vulnerable or not?). Only when someone points at the code that is
bad, in public, and it is agreed that it is bad, only then should a
security update be made.
One (somewhat costly) way to solve this would be to have two kinds of
security updates. One is made early and with information not
available to the community, the other is made only when the community
can verify security bugs. Users can decide which one they want to
trust.
Anyone share my concerns? </troll ;-)>
Anne Carasik <gator@cacr.caltech.edu> writes:
> Hi Mark,
>
> From the OpenSSH web page:
>
> "At least one major security vulnerability exists in many deployed
> OpenSSH versions (2.9.9 to 3.3). Please see the ISS advisory, or our own
> OpenSSH advisory on this topic where simple patches are provided for the
> pre-authentication problem. Systems running with UsePrivilegeSeparation
> yes or ChallengeResponseAuthentication no are not affected.
>
> "The 3.4 release contain many other fixes done over a week long audit
> started when this issue came to light. We believe that some of those
> fixes are likely to be important security fixes. Therefore, we urge an
> upgrade to 3.4."
>
> It sounds like there are other security holes fixed as well.
>
> -Anne
>
> This one time, Mark Janssen wrote:
>> >From what I understand, the advisory below is for the security issue
>> we've been buggering over for the last 2-3 days.
>>
>> As I understand it, there is no need to upgrade to openssh 3.3 and use
>> priv-sep code, when we turn of the various challenge-response systems
>> discussed below (BSD-AUTH and SKEY).
>>
>> AFAIK many people don't need these (What does BSD-Auth do on debian)
>> so we should be safe with the old 3.0.2/3.1 SSH packages and these
>> options removed from the default install ???
>>
>> Can anyone shed any light on this...
>>
>>
>> -----Forwarded Message-----
>>
>> From: X-Force <xforce@iss.net>
>> To: bugtraq@securityfocus.com
>> Subject: ISS Advisory: OpenSSH Remote Challenge Vulnerability
>> Date: 26 Jun 2002 09:56:07 -0400
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>>
>> Internet Security Systems Security Advisory
>> June 26, 2002
>>
>> OpenSSH Remote Challenge Vulnerability
>>
>> Synopsis:
>>
>> ISS X-Force has discovered a serious vulnerability in the default
>> installation of OpenSSH on the OpenBSD operating system. OpenSSH is a
>> free version of the SSH (Secure Shell) communications suite and is used
>> as a secure replacement for protocols such as Telnet, Rlogin, Rsh, and
>> Ftp. OpenSSH employs end-to-end encryption (including all passwords) and
>> is resistant to network monitoring, eavesdropping, and connection
>> hijacking attacks. X-Force is aware of active exploit development for
>> this vulnerability.
>>
>> Impact:
>>
>> OpenBSD, FreeBSD-Current, and other OpenSSH implementations may be
>> vulnerable to a remote, superuser compromise.
>>
>> Affected Versions:
>>
>> OpenBSD 3.0
>> OpenBSD 3.1
>> FreeBSD-Current
>> OpenSSH 3.0-3.2.3
>>
>> OpenSSH version 3.3 implements "privilege separation" which mitigates
>> the risk of a superuser compromise. Prior to the release of this
>> advisory, ISS and OpenBSD encouraged all OpenSSH users to upgrade to
>> version 3.3. Versions of FreeBSD-Current built between March 18, 2002
>> and June 23, 2002 are vulnerable to remote superuser compromise.
>> Privilege separation was implemented in FreeBSD-Current on June 23,
>> 2002.
>>
>> Note: OpenSSH is included in many operating system distributions,
>> networking equipment, and security appliances. Refer to the following
>> address for information about vendors that implement OpenSSH:
>> http://www.openssh.com/users.html
>>
>> Description:
>>
>> A vulnerability exists within the "challenge-response" authentication
>> mechanism in the OpenSSH daemon (sshd). This mechanism, part of the SSH2
>> protocol, verifies a user's identity by generating a challenge and
>> forcing the user to supply a number of responses. It is possible for a
>> remote attacker to send a specially-crafted reply that triggers an
>> overflow. This can result in a remote denial of service attack on the
>> OpenSSH daemon or a complete remote compromise. The OpenSSH daemon runs
>> with superuser privilege, so remote attackers can gain superuser access
>> by exploiting this vulnerability.
>>
>> 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. OpenBSD 3.0 and later is distributed with BSD_AUTH enabled.
>> The SKEY and BSD_AUTH options are not enabled by default in many
>> distributions. However, if these options are explicitly enabled, that
>> build of OpenSSH may be vulnerable.
>>
>> Recommendations:
>>
>> Internet Scanner X-Press Update 6.13 includes a check, OpenSshRunning,
>> to detect potentially vulnerable installations of OpenSSH. XPU 6.13 is
>> available from the ISS Download Center at: http://www.iss.net/download.
>> For questions about downloading and installing this XPU, email
>> support@iss.net.
>>
>> 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.
>>
>> Additional Information:
>>
>> ISS X-Force and Black Hat consulting will host a presentation titled,
>> "Professional Source Code Auditing" at Black Hat Briefings USA 2002. The
>> presentation will explore advanced source code auditing techniques as
>> well as secure development best-practices. Please refer to
>> http://www.blackhat.com and
>> http://www.blackhat.com/html/bh-usa-02/bh-usa-02-speakers.html#Dowd for
>> more information.
>>
>> Credits:
>>
>> The vulnerability described in this advisory was discovered and
>> researched by Mark Dowd of the ISS X-Force. ISS would like to thank Theo
>> de Raadt of the OpenBSD Project for his assistance with this advisory.
>>
>>
>>
>> ______
>>
>> About Internet Security Systems (ISS)
>> Founded in 1994, Internet Security Systems (ISS) (Nasdaq: ISSX) is a
>> pioneer and world leader in software and services that protect critical
>> online resources from an ever-changing spectrum of threats and misuse.
>> Internet Security Systems is headquartered in Atlanta, GA, with
>> additional operations throughout the Americas, Asia, Australia, Europe
>> and the Middle East.
>>
>> Copyright (c) 2002 Internet Security Systems, Inc. All rights reserved
>> worldwide.
>>
>> Permission is hereby granted for the electronic redistribution of this
>> document. It is not to be edited or altered in any way without the
>> express written consent of the Internet Security Systems X-Force. If you
>> wish to reprint the whole or any part of this document in any other
>> medium excluding electronic media, please email xforce@iss.net for
>> permission.
>>
>> Disclaimer: The information within this paper may change without notice.
>> Use of this information constitutes acceptance for use in an AS IS
>> condition. There are NO warranties, implied or otherwise, with regard to
>> this information or its use. Any use of this information is at the
>> user's risk. In no event shall the author/distributor (Internet Security
>> Systems X-Force) be held liable for any damages whatsoever arising out
>> of or in connection with the use or spread of this information.
>>
>> X-Force PGP Key available on MIT's PGP key server and PGP.com's key
>> server, as well as at http://www.iss.net/security_center/sensitive.php
>>
>> Please send suggestions, updates, and comments to: X-Force
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: 2.6.2
>>
>> iQCVAwUBPRnHMDRfJiV99eG9AQHc3wQApUjGfFHFybhfo8vCqlNZ63eEu7ehQyiF
>> lrufj/P7q2cFY/VLICepeDtLhP52bcchNm3WTlaIT3wWLnZzObvgtabHOIax0Z7t
>> oob/Li9+NTB2abwvQiFoX37DPmbhFJ6p1UxgfvVQ6+77nPZse/ID+EFSwLVGL45t
>> ak0sHKrvD0o=
>> =MfYf
>> -----END PGP SIGNATURE-----
>>
>>
>>
>> --
>> To UNSUBSCRIBE, email to debian-security-request@lists.debian.org
>> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>>
>
> --
> .-"".__."``". Anne Carasik, System Administrator
> .-.--. _...' (/) (/) ``' gator at cacr dot caltech dot edu
> (O/ O) \-' ` -="""=. ', Center for Advanced Computing Research
> ~`~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To UNSUBSCRIBE, email to debian-security-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: