作者 主題: CERT Advisory CA-2003-24 Buffer Management Vulnerability in OpenSSH  (閱讀 4507 次)

0 會員 與 1 訪客 正在閱讀本文。

abelyang

  • 酷!學園 學長們
  • 俺是博士!
  • *****
  • 文章數: 1097
    • 檢視個人資料
更不更新看個人囉~只能說,只要你有用 openssh 的,都有漏洞就是了
(因為沒有問題的版本昨天才出...沒有問題版本出來後, CERT 才會公布漏洞提醒大家,不然時間沒有這麼巧合的... :D )
打睹,三天內就會有 exploit code 出來了  :o


-----BEGIN PGP SIGNED MESSAGE-----

CERT Advisory CA-2003-24 Buffer Management Vulnerability in OpenSSH

   Original release date: September 16, 2003
   Last revised: --
   Source: CERT/CC

   A complete revision history can be found at the end of this file.


Systems Affected

     * Systems running versions of OpenSSH prior to 3.7
     * Systems  that  use  or  derive  code  from  vulnerable versions of
       OpenSSH


Overview

   There  is  a  remotely  exploitable  vulnerability in a general buffer
   management  function  in  versions  of  OpenSSH prior to 3.7. This may
   allow  a  remote  attacker  to corrupt heap memory which could cause a
   denial-of-service  condition.  It may also be possible for an attacker
   to execute arbitrary code.


I. Description

   A  vulnerability exists in the buffer management code of OpenSSH. This
   vulnerability  affects  versions prior to 3.7. The error occurs when a
   buffer is allocated for a large packet. When the buffer is cleared, an
   improperly  sized  chunk of memory is filled with zeros. This leads to
   heap corruption, which could cause a denial-of-service condition. This
   vulnerability may also allow an attacker to execute arbitrary code.
   This vulnerability is described in an advisory from OpenSSH

     <http://www.openssh.com/txt/buffer.adv>

   and in FreeBSD-SA-03:12:

     <ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-03:12.
     openssh.asc>

   Other  systems  that  use or derive code from OpenSSH may be affected.
   This   includes  network  equipment  and  embedded  systems.  We  have
   monitored incident reports that may be related to this vulnerability.

   Vulnerability Note VU#333628 lists the vendors we contacted about this
   vulnerability. The vulnerability note is available from

     <http://www.kb.cert.org/vuls/id/333628>

   This   vulnerability   has   been   assigned   the   following  Common
   Vulnerabilities and Exposures (CVE) number:

     http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0693


II. Impact

   While  the  full  impact  of  this  vulnerability is unclear, the most
   likely  result  is  heap  corruption,  which could lead to a denial of
   service.

   If it is possible for an attacker to execute arbitrary code, then they
   may  be  able  to  so with the privileges of the user running the sshd
   process,  typically  root. This impact may be limited on systems using
   the privilege separation (privsep) feature available in OpenSSH.


III. Solution

Upgrade to OpenSSH version 3.7

   This  vulnerability  is  resolved  in  OpenSSH  version  3.7, which is
   available from the OpenSSH web site at

     <http://www.openssh.com/>

Apply a patch from your vendor

   A patch for this vulnerability is included in the OpenSSH advisory at

     <http://www.openssh.com/txt/buffer.adv>

   This  patch  may  be manually applied to correct this vulnerability in
   affected  versions  of OpenSSH. If your vendor has provided a patch or
   upgrade,  you  may  want  to apply it rather than using the patch from
   OpenSSH.  Find information about vendor patches in Appendix A. We will
   update this document as vendors provide additional information.

Use privilege separation to minimize impact

   System  administrators  running  OpenSSH versions 3.2 or higher may be
   able  to  reduce  the  impact  of  this  vulnerability by enabling the
   "UsePrivilegeSeparation"    configuration   option   in   their   sshd
   configuration  file.  Typically,  this  is  accomplished by creating a
   privsep user, setting up a restricted (chroot) environment, and adding
   the following line to /etc/ssh/sshd_config:

     UsePrivilegeSeparation yes

   This  workaround  does  not  prevent  this  vulnerability  from  being
   exploited,  however  due  to  the  privilege separation mechanism, the
   intruder  may  be  limited  to  a  constrained chroot environment with
   restricted   privileges.   This   workaround  will  not  prevent  this
   vulnerability  from  creating  a  denial-of-service condition. Not all
   operating  system  vendors  have  implemented the privilege separation
   code,  and on some operating systems it may limit the functionality of
   OpenSSH.  System administrators are encouraged to carefully review the
   implications  of  using  the workaround in their environment and use a
   more  comprehensive solution if one is available. The use of privilege
   separation   to   limit   the  impact  of  future  vulnerabilities  is
   encouraged.


Appendix A. - Vendor Information

   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 the revision history.
   Additional  vendors  who  have not provided direct statements, but who
   have  made public statements or informed us of their status are listed
   in VU#333628. If a vendor is not listed below or in VU#333628, we have
   not received their comments.

Bitvise

     Our  software  shares  no codebase with the OpenSSH implementation,
     therefore  we  believe that, in our products, this problem does not
     exist.

Cray, Inc.

     Cray  Inc.  supports  OpenSSH  through its Cray Open Software (COS)
     package.  Cray is vulnerable to this buffer management error and is
     in  the  process  of compiling OpenSSH 3.7. The new version will be
     made available in the next COS release.

Debian

     A  fix for the buffer management vulnerability is available for the
     ssh package at http://www.debian.org/security/2003/dsa-382

     A  fix  for  the  ssh-krb5  (ssh  with kerberos support) package is
     available at http://www.debian.org/security/2003/dsa-383

Mandrake Software

     Mandrake  Linux  is  affected  and  MDKSA-2003:090 will be released
     today with patched versions of OpenSSH to resolve this issue.

PuTTY

     PuTTY  is  not  based on the OpenSSH code base, so it should not be
     vulnerable to any OpenSSH-specific attacks.
     _________________________________________________________________

   The  CERT/CC  thanks  Markus  Friedl  of  the  OpenSSH project for his
   technical assistance in producing this advisory.
     _________________________________________________________________

   Authors: Jason A. Rafail and Art Manion
   ______________________________________________________________________

   This document is available from:
   <http://www.cert.org/advisories/CA-2003-24.html>
   ______________________________________________________________________

CERT/CC Contact Information

   Email: cert@cert.org
          Phone: +1 412-268-7090 (24-hour hotline)
          Fax: +1 412-268-6989
          Postal address:
          CERT Coordination Center
          Software Engineering Institute
          Carnegie Mellon University
          Pittsburgh PA 15213-3890
          U.S.A.

   CERT/CC   personnel   answer  the  hotline  08:00-17:00  EST(GMT-5)  /
   EDT(GMT-4)  Monday  through  Friday;  they are on call for emergencies
   during other hours, on U.S. holidays, and on weekends.

Using encryption

   We  strongly  urge you to encrypt sensitive information sent by email.
   Our public PGP key is available from
   
     <http://www.cert.org/CERT_PGP.key>

   If  you  prefer  to  use  DES,  please  call the CERT hotline for more
   information.

Getting security information

   CERT  publications  and  other security information are available from
   our web site
   
     <http://www.cert.org/>

   To  subscribe  to  the CERT mailing list for advisories and bulletins,
   send  email  to majordomo@cert.org. Please include in the body of your
   message

   subscribe cert-advisory

   *  "CERT"  and  "CERT  Coordination Center" are registered in the U.S.
   Patent and Trademark Office.
   ______________________________________________________________________

   NO WARRANTY
   Any  material furnished by Carnegie Mellon University and the Software
   Engineering  Institute  is  furnished  on  an  "as is" basis. Carnegie
   Mellon University makes no warranties of any kind, either expressed or
   implied  as  to  any matter including, but not limited to, warranty of
   fitness  for  a  particular purpose or merchantability, exclusivity or
   results  obtained from use of the material. Carnegie Mellon University
   does  not  make  any warranty of any kind with respect to freedom from
   patent, trademark, or copyright infringement.
   ______________________________________________________________________

   Conditions for use, disclaimers, and sponsorship information

   Copyright 2003 Carnegie Mellon University.

   Revision History

     September 16, 2003: Initial release

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8

iQCVAwUBP2eByzpmH2w9K/0VAQGnaAP/Zb54OjkSVC0594mOAQDT5s92IOUHY2ND
aonp3h1jPmg6kJ6jJyh1Z4ZyC3tFoQa8EnAgKs7tFYJHr/65t4ASLycB/X/tJu1T
KGIG+yJ/MP9OZ0s/i2Rp95x1u8wrQHoq1TuDs+sJ6clu638dFcgZk2CzZSojPIr9
hgzCzPOAscA=
=Xysb
-----END PGP SIGNATURE-----

netman

  • 管理員
  • 俺是博士!
  • *****
  • 文章數: 17379
    • 檢視個人資料
    • http://www.study-area.org
要是用 RPM 的系統,可以到中山那邊抓 source rpm :

ftp://openbsd.nsysu.edu.tw/pub/OpenBSD/OpenSSH/portable/rpm/SRPMS/openssh-3.7.1p1-1.src.rpm

若 rebuild 碰到 XFree86-devel 跟 pkgconfig 的相依性問題,
可先用 rpm -ivh 將 src.rpm 裝好,
然後修改 SPECS/openssh.spec ,設如下兩行為 1 :
%define no_x11_askpass 1
%define no_gnome_askpass 1

然後再繼續 rebuild 吧...

要是 RPM 不熟,可先補 rpm 的功課:
http://www.rpm.org/RPM-HOWTO/
http://www.rpm.org/max-rpm/
http://phorum.study-area.org/~lman/920726/TnLUG-20030726_1.DAT
http://phorum.study-area.org/~lman/920726/TnLUG-20030726_2.DAT
http://phorum.study-area.org/~lman/920726/TnLUG-20030726_3.DAT
http://www.study-area.org/linux/src/package_man.txt