osdir.com
mailing list archive F.A.Q. -since 2001!



Subject: [EEYEB-20060703] IBM eGatherer ActiveX Code
Execution Vulnerability - msg#00005

List: security.vulnerabilities.watch.announce

Mail Archive Navigation:
by Date: Prev Next Date Index by Thread: Prev Next Thread Index

IBM eGatherer ActiveX Code Execution Vulnerability

Release Date:
August 16, 2006

Date Reported:
July 3, 2006

Patch Development Time (in days):
44

Severity:
High (Remote Code Execution)

Vendor:
IBM / Lenovo

Systems Affected:
Windows NT 4.0 (All versions)
Windows 2000 (All versions)
Windows XP (All versions)
Windows 2003 (All versions)

Overview:
eEye Digital Security has discovered a security vulnerability in IBM's
eGatherer ActiveX control. This is the second vulnerability found in
this control by eEye Research, the first being from Drew Copley
(http://www.eeye.com/html/research/advisories/AD20040615B.html). This
control is typically installed by default on IBM workstations and
laptops, and is used by default for auto-finding drivers/updates on
IBM's/Lenovo's support site.

IBM / Lenovo describes this ActiveX control as follows:
"The auto-detect feature automatically finds your system's machine-type,
model, and serial number to help you get the files and information you
need quickly and easily. *It does not collect any personal information
or compromise the security of your system in any way.*"

Despite their promise for not "comprimising the security of the system
in any way", a buffer overflow exists within the handling of a parameter
of the ActiveX control that would allow a remote attacker to reliably
overwrite the stack with arbitrary data and execute arbitrary code
through the web browser with the privileges of the logged in user.

Technical Details:
The vulnerability exists within the RunEgatherer functionwithin the
ActiveX. This method accepts one function, the specified file name for
the eGatherer log output. It should be noted that even when setting the
parameter with legitimate paths for output, the ActiveX remains to only
write the log file to the SystemDrive. By filling the single paramater
with a large string, a straight stack overflow occurs. The following
sample would reproduce the crash for vulnerable ActiveX controls:

##<html>
##<object classid='clsid:74FFE28D-2378-11D5-990C-006094235084'
id='notCompromising'></object>
##<script language='vbscript'>
##overflowBuffer=String(300,"A")
##notCompromising.RunEgatherer overflowBuffer
##</script>


The vulnerable code is as follows:

.text:10003B73 push dword ptr [ebp+0Ch] ; lpString
.text:10003B76 call ds:lstrlenW
.text:10003B7C lea edi, [eax+eax+2]
.text:10003B80 mov eax, edi
.text:10003B82 add eax, 3
.text:10003B85 and al, 0FCh
.text:10003B87 call __alloca_probe
.text:10003B8C mov esi, esp
.text:10003B8E push ebx ; lpUsedDefaultChar = 0x0
.text:10003B8F push ebx ; lpDefaultChar = 0x0
.text:10003B90 push edi ; cchMultiByte = 1002 (eax*2 + 2)
.text:10003B91 push esi ; lpMultiByteStr = ESP (STACK)
.text:10003B92 push 0FFFFFFFFh ; cchWideChar = -1
.text:10003B94 push dword ptr [ebp+0Ch] ; lpWideCharStr = ptr to our
string
.text:10003B97 mov [esi], bl
.text:10003B99 push ebx ; dwFlags = 0x0
.text:10003B9A push ebx ; CodePage = 0x0
.text:10003B9B call ds:WideCharToMultiByte

The vulnerability begins with a stack allocation for the string. This
is not in itself vulnerable, but there has yet to be a length check the
supplied string.
The string is copied again one more into memory, slightly below the
first, and then lower-cased:

.text:10003BA1 lea eax, [ebp-118h]
.text:10003BA7 push esi ; unsigned __int8 *
.text:10003BA8 mov esi, ds:_mbscpy
.text:10003BAE push eax ; unsigned __int8 *
.text:10003BAF call esi ; _mbscpy
.text:10003BB1 lea eax, [ebp-118h]
.text:10003BB7 pop ecx
.text:10003BB8 test eax, eax
.text:10003BBA pop ecx
.text:10003BBB jz short loc_10003C23
.text:10003BBD lea eax, [ebp-118h]
.text:10003BC3 push eax ; unsigned __int8 *
.text:10003BC4 call sub_10003C45 ; TOLOWER SUBROUTINE

The original string remains untouched, and all future operations will be
performed on the lower-case string. However, because there were no
length checks on the string, the memory is copied straight into the
undersized stack buffer and causes a simple buffer overflow.


Protection:
Retina (http://www.eeye.com/html/Products/Retina/index.html) Network
Security Scanner has been updated to identify this vulnerability.
Blink (http://www.eeye.com/html/products/blink/index.html) Endpoint
Vulnerability Prevention preemptively protects from this vulnerability.


Vendor Status:
IBM UK has patched the vulnerability in their latest version of the
eGatherer ActiveX control (3.20.0284.0), available here:
http://www-307.ibm.com/pc/support/IbmEgath.cab.


Credit:
Andre Derek Protas


Greetings:
Barnz,D-Rock,Karl,HTP,Marc,Steve,Tequila,Ica,SyScan06,xbxice,The
Fam-Damnly, and (RIT(D|S))+.





Thread at a glance:

Previous Message by Date:

Re: Concurrency-related vulnerabilities in browsers - expect problems

Here's another separate issue that typically causes fault on memory access to website-influenced memory access: http://lcamtuf.coredump.cx/ffoxdie3.html This is separate from the previously presented example (which, remarkably, also had a tendency to trigger an unrelated call stack overflow due to XML parsing glitch on some platforms, which caused some confusion - my bad). Note that because it depends on timing more heavily, it may not work in the first shot on all computers (though it should). /mz

Next Message by Date:

Re: Re: Concurrency-related vulnerabilities in browsers - expect problems

Some interesting work. For those who haven't made the connection yet - concurrency issues probably go far beyond just web browsers. It's a safe bet that *any* software that's multi-threaded, multi-process, event-based, or asynchronous could have these sorts of issues. Traditional data manipulation techniques probably won't be effective in finding them. In other words - concurrency is a rich area for future research, and web browser bugs are probably the tip of the iceberg. - Steve

Previous Message by Thread:

Concurrency-related vulnerabilities in browsers - expect problems

Good morning, "Fame-hungry sociopath torches cars, finds browser flaws WARSAW, Poland (AP) -- police are on a look out for a local adolescent vandal who continues to terrorize local IT workers in what appears to be a bizzare bid for fame. Larry Seltzer reports from the scene." Well, I just had to do this, forgive me. There seems to be an interesting class of concurrency-related bugs in popular browsers. This is quite similar to signal-handling flaws you might be familiar with: many browser events can be triggered asynchronously, for example using Javascript timers, while some components of the browser are still running. In many cases, a new action might be initiated that interferes with or counters the interrupted (or still executing) task. Problems like this may leave the program in inconsistent state, and later cause double frees or related issues. That usually opens the door to system compromise through careful manipulation of memory contents. The attacks would depend heavily on network latency and jitter, but can be executed. Given that the tip of that iceberg has been probed recently - for example here: http://www.mozilla.org/security/announce/2006/mfsa2006-46.html - I assumed it is now the time to post my older example. A fairly reliable example is when Firefox is interrupted by a Javascript handler while parsing a deeply nested XML document for display. If the browser is then redirected from the script to a new location, the unfinished parsing process is aborted, and all its structures are freed - but these were not left in the expected state by the parser. This is a demo that will usually crash Firefox in a couple of seconds (SEGV on Linux and MacOS, silent crashes on Windows): http://lcamtuf.coredump.cx/ffoxdie.html Have fun! PS. For the easily amused: MSIE loves "<DT><H1 STYLE=width:1px><LI></H1>" /mz http://lcamtuf.coredump.cx/

Next Message by Thread:

Cisco Security Advisory: Cisco VPN 3000 Concentrator FTP Management Vulnerabilities

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco VPN 3000 Concentrator FTP Management Vulnerabilities Document ID: 71141 Advisory ID: cisco-sa-20060823-vpn3k http://www.cisco.com/warp/public/707/cisco-sa-20060823-vpn3k.shtml Revision 1.0 For Public Release 2006 August 23 1600 UTC (GMT) - ----------------------------------------------------------------------- Contents ======== Summary Affected Products Details Impact Software Versions and Fixes Workarounds Obtaining Fixed Software Exploitation and Public Announcements Status of This Notice: FINAL Distribution Revision History Cisco Security Procedures - ----------------------------------------------------------------------- Summary ======= The Cisco VPN 3000 series concentrators are affected by two vulnerabilities when file management via File Transfer Protocol (FTP) is enabled that could allow authenticated or unauthenticated attackers to execute certain FTP commands and delete files on the concentrator. None of the vulnerabilities allows unauthorized users to transfer files from or to the concentrator. Cisco has made free software available to address these vulnerabilities for affected customers. There are workarounds available to mitigate these vulnerabilities as well. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20060823-vpn3k.shtml. Affected Products ================= Vulnerable Products +------------------ Cisco VPN 3000 series concentrators 3005, 3015, 3020, 3030, 3060, and the 3080 are affected by these vulnerabilities if they are running a vulnerable software version and if the concentrator is configured to use FTP as a management protocol. FTP as a management protocol is enabled by default. Vulnerable software versions are: * Any version prior to 4.1 * Any 4.1.x version prior to, and including, 4.1(7)L * Any 4.7.x version prior to, and including, 4.7(2)F There are two ways to determine whether the FTP protocol is enabled as a file management protocol: using the web Graphical User Interface (GUI), or using a Command-Line Interface (CLI) via a console, telnet, or Secure Shell (SSH) connection. To use the GUI to determine whether the FTP protocol is enabled as a file management protocol, connect to the web administration interface of the concentrator via the URL: https://<IP address of concentrator>/admin/ Then log in to the concentrator using the device administrator credentials and go to the screen "Configuration | System | Management Protocols | FTP". This screen will indicate whether the FTP server on the concentrator is enabled. To accomplish the same thing using the CLI, log in to the concentrator using the chosen access method (console, Telnet or SSH) and go to the same screen ("Configuration -> System Management -> Management Protocols -> Configure FTP"). The prompt will indicate with a number whether the FTP server is enabled. Products Confirmed Not Vulnerable +-------------------------------- The Cisco VPN 3002 Hardware Client is not affected by these vulnerabilities. Please note that Cisco VPN 3000 Series concentrators are not affected by these vulnerabilities if FTP is not configured as a management protocol. No other Cisco products are currently known to be affected by these vulnerabilities. Details ======= The Cisco VPN 3000 series concentrators are a family of purpose-built, remote access Virtual Private Network (VPN) platforms for data encryption and authentication. The File Transfer Protocol is an application-layer protocol that allows transfer of files between TCP/IP hosts. It uses Transmission Control Protocol (TCP) as the transport protocol and supports user authentication. The Cisco VPN 3000 series concentrators can be configured to use the FTP protocol to manage files stored on the concentrator, like configuration files and certificates. Files can be uploaded to, or downloaded from, the concentrator for backup and configuration purposes. Two vulnerabilities affect the Cisco VPN 3000 series concentrators when FTP is enabled as a file management protocol. By exploiting these vulnerabilities, an attacker could execute the following FTP commands: * CWD - Change working directory * MKD - Create (make) a directory * CDUP - Change directory to the directory one level up * RNFR - Rename file * SIZE - Get file size * RMD - Remove directory These vulnerabilities are documented in Cisco Bug IDs CSCse10733 and CSCse10753. None of these vulnerabilities allows unauthorized users to download or upload files from/to the concentrator. Impact ====== Successful exploitation of these vulnerabilities may allow an attacker to: * Perform network reconnaissance via the "CWD", "CDUP", and "SIZE" FTP commands. * Change the configuration of the concentrator by renaming or deleting configuration and certificate files via the "RNFR" and "RMD" FTP commands. Please note that since none of these vulnerabilities allows an attacker to upload or download files to/from the concentrator, it is not possible to obtain the configuration of a device or to upload a modified configuration by exploiting the vulnerabilities. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center ("TAC") or your contracted maintenance provider for assistance. Both vulnerabilities are fixed in versions 4.1(7)M and 4.7(2)G of the VPN 3000 Series Concentrators software. Fixed versions of the Cisco VPN 3000 Series concentrators software can be downloaded from the following location: http://www.cisco.com/pcgi-bin/tablebuild.pl/vpn3000-3des Workarounds =========== Disabling FTP +------------ If FTP is not needed to manage the VPN 3000 concentrator, network security best practices recommend that it be disabled. This will completely eliminate the vulnerability. Secure alternatives to FTP include Secure Hyper-Text Transfer Protocol (HTTPS) and Secure Copy (SCP) via Secure Shell (SSH). The use of FTP as a management protocol can be disabled by connecting to the web administration interface of the concentrator via the URL: https://<IP address of concentrator>/admin/ and then logging in to the concentrator using the device administrator credentials, going to the screen "Configuration | System | Management Protocols | FTP", and unchecking the "Enable" checkbox. Limiting FTP Access +------------------ It is possible to limit the exposure of the concentrator by permitting remote FTP management connections only from known, trusted IP addresses. This is also considered a network security best practice. Limiting FTP access to specific IP addresses can be accomplished on the VPN 3000 Series concentrators by defining rules and filters. The traffic filters can be mapped to the interfaces, LAN-to-LAN tunnels, and VPN groups. Traffic rules and filters are configured via the GUI in the screen "Configuration | Policy Management | Traffic Management". To allow FTP access only from specific IP addresses, at least two traffic rules must be defined. The first rule would permit FTP traffic from a specific, trusted IP address or IP subnet. The second rule would deny all other FTP traffic directed at the private interface. The parameters of the first rule could be: * Rule Name: permit_ftp_in * Direction: Inbound * Action: Forward * Protocol: TCP * Source Address/Wildcard-mask: <Allowed IP address range> * Destination Address/Wildcard-mask: <IP address of private interface>/0.0.0.0 * TCP/UDP Source Port: Range, from 0 to 65535 * TCP/UDP Destination Port: FTP (21) This rule will permit inbound TCP port 21 (FTP) traffic but only when the traffic originates from a specific IP address range. The parameters of the second rule could be: * Rule Name: deny_ftp_in * Direction: Inbound * Action: Drop and Log * Protocol: TCP * Source Address/Wildcard-mask: 0.0.0.0/255.255.255.255 * Destination Address/Wildcard-mask: <IP address of private interface>/0.0.0.0 * TCP/UDP Source Port: Range, from 0 to 65535 * TCP/UDP Destination Port: FTP (21) This rule will drop and log all inbound TCP port 21 (FTP) traffic that is directed at the IP address of the private interface. Note: When new rules are added to a filter, the new rules get added at the bottom of the list of existing rules in the filter. The concentrator processes rules in a filter in sequential order, so if at the bottom of the list there is a rule that permits all traffic (which is the case with the predefined "Private" filter applied by default to the Private interface), then the new rules will not be executed. For this reason it is important that the new rules intended to allow FTP traffic only from trusted addresses be moved to the top of the list of rules. When the traffic rules have been created, they need to be added to a filter by going to the GUI screen "Configuration | Policy Management | Traffic Management | Filters", selecting the desired filter from the list, clicking on the "Assign Rules to Filter" button, and then selecting the new filter rules and clicking on the "<< Add" button. To completely protect the VPN 3000 concentrator from unauthorized FTP traffic, the filter with the new traffic rules needs to be applied to the following: * Interfaces: a filter is applied to an interface by going to the GUI screen "Configuration | Interfaces", clicking on an interface name, and then selecting a filter in the "General" tab. By default the predefined filter "Private" is applied to the Private interface and the predefined filter "Public" is applied to the "Public" interface. The "Private" filter is very permissive and it is recommended that the above rules to limit FTP management traffic be added to this filter. The "Public" filter does not permit FTP traffic by default, and if changes have been made to permit FTP traffic, it is recommended that rules are added to only permit FTP traffic to the concentrator from specific IP addresses, as described above. * LAN-to-LAN tunnels: a filter is applied to a LAN-to-LAN tunnel by going to the GUI screen "Configuration | Tunneling and Security | IPSec | LAN-to-LAN", selecting the LAN-to-LAN connection and clicking the "Modify" button, and then selecting the specific filter in the "Modify an IPSec LAN-to-LAN connection" screen. By default a LAN-to-LAN connection does not have any filter applied to it. * Remove Access VPN tunnels: a filter is applied to a remote access VPN group by going to the GUI screen "Configuration | User Management | Groups", selecting the VPN group and clicking the "Modify Group" button, and then selecting the specific filter in the "General" tab of the "Modify Group" screen. By default a VPN group does not have any filter applied to it. By adding these two traffic rules to the filter applied to the an interface, LAN-to-LAN tunnel, and VPN group, the FTP traffic directed at the concentrator will only be allowed from the specific, trusted IP addresses, regardless of where the IP addresses are located, i.e. internal network or across a VPN tunnel. FTP traffic directed at the concentrator from anywhere else will be dropped and logged. All other FTP traffic is not affected by these rules. If you do not wish to define multiple filters for each interface and the VPN tunnels, you can add the two traffic rules described above to the default "Private" filter and then apply this filter to the Private interface as well as to any LAN-to-LAN connections and Remote Access VPN groups. Please note that using the "Access Control List" feature ("Administration | Access Rights | Access Control List") to control FTP access will not protect against these vulnerabilities because the check for valid IP addresses takes place at authentication time, and the actual vulnerability described in this document takes place before authentication. In addition to the access control mechanism that can be implemented on the VPN 3000 concentrator itself, FTP access to the VPN 3000 concentrator could be blocked as part of an Infrastructure Access Control List (ACL) on screening routers, switches and firewalls controlling all access to the trusted network. Infrastructure ACLs are considered a network security best practice and should be considered as a long-term addition to good network security, as well as a workaround for this specific vulnerability. The white paper entitled "Protecting Your Core: Infrastructure Protection Access Control Lists" presents guidelines and recommended deployment techniques: http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a1a55.shtml Backing Up Configuration and Certificates +---------------------------------------- Always keep backup copies, outside of the concentrator's file system, of the concentrator's configuration and certificates. Management of configuration files can be done from the GUI screen "Administration | File Management". Please refer to the "File Management" section of the VPN 3000 Series Concentrator Reference, Volume II, for additional information: http://www.cisco.com/en/US/products/hw/vpndevc/ps2284/products_administration_guide_chapter09186a00803ef263.html Management of certificates can be done from the GUI screen "Administration | Certificate Management". Please refer to the "Certificate Management" section of the VPN 3000 Series Concentrator Reference, Volume II, for additional information: http://www.cisco.com/en/US/products/hw/vpndevc/ps2284/products_administration_guide_chapter09186a00803ef352.html Obtaining Fixed Software ======================== Cisco has made free software available to address this vulnerability for affected customers. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment. Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at http://www.cisco.com/public/sw-license-agreement.html, or as otherwise set forth at Cisco.com Downloads at http://www.cisco.com/public/sw-center/sw-usingswc.shtml. Do not contact either "psirt@xxxxxxxxx" or "security-alert@xxxxxxxxx" for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com. Customers using Third-party Support Organizations +------------------------------------------------ Customers whose Cisco products are provided or maintained through prior or existing agreement with third-party support organizations such as Cisco Partners, authorized resellers, or service providers should contact that support organization for guidance and assistance with the appropriate course of action in regards to this advisory. The effectiveness of any workaround or fix is dependent on specific customer situations such as product mix, network topology, traffic behavior, and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround or fix is the most appropriate for use in the intended network before it is deployed. Customers without Service Contracts +---------------------------------- Customers who purchase direct from Cisco but who do not hold a Cisco service contract and customers who purchase through third-party vendors but are unsuccessful at obtaining fixed software through their point of sale should get their upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows. * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac@xxxxxxxxx Have your product serial number available and give the URL of this notice as evidence of your entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Refer to http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml for additional TAC contact information, including special localized telephone numbers and instructions and e-mail addresses for use in various languages. Exploitation and Public Announcements ===================================== The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerability described in this advisory. This vulnerability was reported to Cisco by the NCC Group (http://www.nccgroup.com.) Cisco would like to thank the NCC Group for reporting this vulnerability and working with us towards resolution of this problem. Status of This Notice: FINAL ============================ THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. Distribution ============ This advisory is posted on Cisco's worldwide website at http://www.cisco.com/warp/public/707/cisco-sa-20060823-vpn3k.shtml. In addition to worldwide web posting, a text version of this notice is clear-signed with the Cisco PSIRT PGP key and is posted to the following e-mail and Usenet news recipients. * cust-security-announce@xxxxxxxxx * first-teams@xxxxxxxxx * bugtraq@xxxxxxxxxxxxxxxxx * vulnwatch@xxxxxxxxxxxxx * cisco@xxxxxxxxxxxxxxxxx * cisco-nsp@xxxxxxxxxxxxxxx * full-disclosure@xxxxxxxxxxxxxxxxx * comp.dcom.sys.cisco@xxxxxxxxxxxxxxxxxx Future updates of this advisory, if any, will be placed on Cisco's worldwide website, but may or may not be actively announced on mailing lists or newsgroups. Users concerned about this problem are encouraged to check the above URL for any updates. Revision History ================ +----------------------------------------+ | Revision | | Initial | | 1.0 | 2006-August-23 | public | | | | release. | +----------------------------------------+ Cisco Security Procedures ========================= Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's worldwide website at http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html. This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at http://www.cisco.com/go/psirt. - ----------------------------------------------------------------------- All contents are Copyright 1992-2006 Cisco Systems, Inc. All rights reserved. Important Notices and Privacy Statement. - ----------------------------------------------------------------------- Updated: Aug 23, 2006 Document ID: 71141 - ----------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFE7Hqc8NUAbBmDaxQRAkAKAJ9rPd/IPTT7Fm3l49FEfUzxq5SHDACgonCn zQJuZOaLSNNoxJt4HXsttVU= =L9om -----END PGP SIGNATURE-----
blog comments powered by Disqus

Home | News | Sitemap | FAQ | advertise | OSDir is an Inevitable website. GBiz is too!