Re: [Fwd: ISS Advisory: OpenSSH Remote Challenge Vulnerability]
On Wed, 2002-06-26 at 14:59, Lupe Christoph wrote: > I've spent several hours updating left and right, and now this? > How shall I justify this to my client? I can't really charge for > falling for Theo. Seems I took a firm stand and bent over for him. See Wichert's message: <[EMAIL PROTECTED]> Apparently, the advisory does not give a thorough account of what is vulnerable. signature.asc Description: This is a digitally signed message part
Re: [Fwd: ISS Advisory: OpenSSH Remote Challenge Vulnerability]
On Wednesday, 2002-06-26 at 18:14:35 +0200, 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- > ... > 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. I just had a look at openssh-3.0.2p1/debian/rules (3.0.2p1 is included with woody, before applying woody/updates: ./configure --prefix=/usr --sysconfdir=/etc/ssh --libexecdir=/usr/lib --mandir=/usr/share/man --with-tcp-wrappers --with-xauth=/usr/bin/X11/xauth --with-rsh=/usr/bin/rsh --with-default-path=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin --disable-suid-ssh --with-pam --with-4in6 --with-ipv4-default And ./configure --help says: --with-skey[=PATH] Enable S/Key support (optionally in PATH) So I'd assume S/Key is not included in Woody's 3.0.2p1 .deb. (I'm not familiar with package building in Debian, so I may be wrong.) If it really isn't all the hoopla was in vain. Thank you, Theo. I scrapped OpenBSD because of him. He has confirmed my opinion. Try to avoid anything contaminated by Theo de Raadt. I've spent several hours updating left and right, and now this? How shall I justify this to my client? I can't really charge for falling for Theo. Seems I took a firm stand and bent over for him. Lupe Christoph -- | [EMAIL PROTECTED] | http://www.lupe-christoph.de/ | | I have challenged the entire ISO-9000 quality assurance team to a | | Bat-Leth contest on the holodeck. They will not concern us again. | | http://public.logica.com/~stepneys/joke/klingon.htm| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: ISS Advisory: OpenSSH Remote Challenge Vulnerability]
I don't see a better way of handling the OpenSSH announcement. More details or a patch would have allowed people to start writing exploits, at least they warned users of an upcoming bug and provided a work around. The OpenSSH team had to communicate with many vendors and eventually the details would have leaked. While debian may have released patched ssh packages right away, how many thousands of users of other vendors out there wouldn't have had a patch? The apache announcement was just a mess though... -Greg > *raises hand* > > Both the Apache and OpenSSH announcements were done poorly, without > any reasonable thought given to the user community. > > They should be taken out and shot ;-) (IMHO). > > -Anne -- --SupplyEdge--- Greg Hunt 800-733-3380 x 107 [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: ISS Advisory: OpenSSH Remote Challenge Vulnerability]
Hi Simon, This one time, [EMAIL PROTECTED] wrote: > 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. Always, always, check the digital signature. I don't think that Theo and co. would want to distribute a worm in this way. This would defeat their purpose for existence in the UNIX security world. I agree though.. it's really poorly handled. I really hope that's what the deb packagers do before creating the package. Speaking of which.. When is Debian going to implement SHA-1 checksums or gpg sigs into the apt-get, dpkg, and the debs before installing? This just trusting the deb source is really scary.. > 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. Wow, this and Apache all in a matter of weeks ;-). *sigh* I agree, especially since any monkey can go and audit the source themselves. > 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. I would say use one or the other, but not both. This is something the security community should decide, not the users. You'll confuse the poor folks ;) > Anyone share my concerns? *raises hand* Both the Apache and OpenSSH announcements were done poorly, without any reasonable thought given to the user community. They should be taken out and shot ;-) (IMHO). -Anne -- .-"".__."``". Anne Carasik, System Administrator .-.--. _...' (/) (/) ``' gator at cacr dot caltech dot edu (O/ O) \-' ` -="""=.', Center for Advanced Computing Research ~`~~ pgphq6WqICg8G.pgp Description: PGP signature
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? Anne Carasik <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> >> 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 acce
Re: [Fwd: ISS Advisory: OpenSSH Remote Challenge Vulnerability]
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 <[EMAIL PROTECTED]> > 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 > [EMAIL PROTECTED] > > 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
