-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Core Security Technologies - Corelabs Advisory http://corelabs.coresecurity.com/ Cisco WebEx .atp and .wrf Overflow Vulnerabilities 1. *Advisory Information* Title: Cisco WebEx .atp and .wrf Overflow Vulnerabilities Advisory ID: CORE-2010-1001 Advisory URL: [http://www.coresecurity.com/content/webex-atp-and-wrf-overflow-vulnerab ilities] Date published: 2011-01-31 Date of last update: 2011-01-31 Vendors contacted: Cisco Release mode: Coordinated release 2. *Vulnerability Information* Class: Stack-based Buffer Overflow [CWE-121], Stack-based Buffer Overflow [CWE-121] Impact: Code execution Remotely Exploitable: Yes (client-side) Locally Exploitable: No CVE Name: CVE-2010-3269, CVE-2010-3270 Bugtraq ID: N/A 3. *Vulnerability Description* There are stack overflows on WebEx [1] that can be exploited by sending maliciously crafted .atp and .wrf files to a vulnerable WebEx user. When opened, these files trigger a reliably exploitable stack based buffer overflow. Code execution is trivially achieved on the .wrf case because WebEx Player allocates a function pointer on the stack that is periodically used in what seems to be a callback mechanism, and also because DEP and ASLR are not enabled. In the .atp case an exception handler can be overwritten on the stack, and most registers can be trivially overwritten. 4. *Vulnerable packages* . Contact Cisco for a list of vulnerable versions. 5. *Non-vulnerable packages* . Contact Cisco. 6. *Vendor Information, Solutions and Workarounds* All clients of WebEx Meeting Center should now be running a patched version according to Cisco. A non-vulnerable version of WebEx Player should be available at [http://www.webex.com/downloadplayer.html]. 7. *Credits* These vulnerabilities were discovered and researched by Federico Muttis, Sebastian Tello and Manuel Muradas from Core Security Technologies during Bugweek 2010 as part of the "Cisco Baby Cisco!" team [2]. The publication of this advisory was coordinated by Pedro Varangot. 8. *Technical Description* 8.1. *WebEx Player .wrf Buffer Overflow [CVE-2010-3269]* WebEx Player can be used to playback recordings of WebEx sessions. These recordings can be stored using the .wrf closed and undocumented file format. By fuzzing this file format a crash due to a stack overflow was discovered. A function pointer can be overwritten in the stack resulting in reliable code execution because of the fact that DEP and ASLR are disabled. This vulnerability can also be exploited by publishing a .wrf video file in a meeting, resulting in the compromise of the meeting's participants. /----- .text:6070C272 loc_6070C272: ; CODE XREF: sub_6070C050+255j .text:6070C272 test esi, esi .text:6070C274 jnz short loc_6070C28F .text:6070C276 push ebx .text:6070C277 call dword ptr [ebp+0Ch] ; call to function pointer on the stack .text:6070C27A add esp, 4 .text:6070C27D test al, al .text:6070C27F jz loc_6070C374 .text:6070C285 mov edi, [ebp+0] .text:6070C288 mov esi, [ebp+4] .text:6070C28B mov eax, [esp+0D98h+var_D80] .text:6070C28F .text:6070C28F loc_6070C28F: ; CODE XREF: sub_6070C050+224j .text:6070C28F mov cl, [edi] ; cl can be controlled, it is read from the malicious .wrf file .text:6070C291 dec esi .text:6070C292 mov [esp+eax+0D98h+var_C8C], cl ; this mov overflows the stack with user controlled values .text:6070C299 mov ecx, [esp+0D98h+var_D84] .text:6070C29D inc edi .text:6070C29E inc eax .text:6070C29F cmp eax, ecx .text:6070C2A1 mov [esp+0D98h+var_D80], eax .text:6070C2A5 jl short loc_6070C272 - -----/ 8.2. *WebEx Meeting Center .atp Buffer Overflow [CVE-2010-3270]* WebEx Meeting Center allows polls to be conducted between all participants of a WebEx session. By serving a specially crafted .atp file (used for conducting polls) the meeting host can then abruptly disconnect from the server, and when another client becomes host and tries to share the .atp file with the other clients arbitrary code execution is possible on his workstation. If his connection to the server is then severed by a malicious payload, the .atp file will be cycled to the next connected client. Reliable code execution is possible because a big chunk of the stack is overwritten (including the SEH), ASLR and DEP are disabled, and SafeSEH seems to be also disabled. We developed trivial examples that take control of EIP using arbitrary characters. 9. *Report Timeline* . 2010-10-04: Core Security Technologies contacts Cisco PSIRT using their provided PGP key notifying them of the vulnerabilities and sending an advisory draft, a proof of concept for the WebEx Player vulnerability, and a proof of concept for the Meeting Center vulnerability including details of how to reproduce both vulnerabilities, and details about the behaviour of the PoC for the Player vulnerability on Windows XP SP2 (which overwrites EIP with 0x41414141 on that platform). October 18th 2010 (a two weeks timeframe) is set as a potential release date for the advisory. . 2010-10-05: Cisco PSIRT contacts Core stating that their development team is out of the office till Friday October 8th. November 15th 2010 is mentioned as an estimated release date for a fix. . 2010-10-05: Core replies to Cisco PSIRT postponing the release date of this advisory for one week, to Monday October 25th, in order to contemplate the fact that Cisco's development team is away from office for the week. Further changes to the release date will be made after receiving technical feedback. November the 15th is mentioned to be a possible date to settle on. . 2010-10-11: Cisco PSIRT replies acknowledging "an exception in WebEx player" but that doesn't overwrite EIP as Core Security Technologies indicated. Cisco notifies that they were not able to reproduce the crash in WebEx Meeting Center. Cisco PSIRT also asks for more detailed information about the version of WebEx Player used. . 2010-10-12: Core sends the requested information, also attaching new proof of concept exploits for the WebEx Player vulnerability (that now executes code and launches "calc.exe"), and further details about the steps needed to reproduce the WebEx Meeting Center crash. Details about the system where the proof of concept for the WebEx Player vulnerability was run are asked. Details about the "exception" are also asked, specially noting that if other registers are overwritten this should be considered as a vulnerability that would possibly lead to reliable code execution even if EIP was not modified (as noted by Core on the e-mail where the PoC was attached). No reply is received to this e-mail. . 2010-10-19: Core resends the previous e-mail asking for news about reproduction of the vulnerability on Cisco's side and asking if there was any problem in the reception or interpretation of the last communication. No reply is received to this e-mail. . 2010-10-28: Core Security Technologies resends the last e-mail, unilaterally rescheduling the publication of this advisory to November 8th 2010, which is closer to Cisco's initial estimation for the release of a fix. Core states its willingness to reschedule this publication date but only under firm commitment from Cisco to working seriously towards fixing this issue in a scheduled timeframe. An updated advisory draft is attached which includes an updated timeline. . 2010-10-30: Cisco PSIRT replies acknowledging the vulnerability, stating that they were able to reproduce code execution results in the currently released version of WebEx, and a crash in their current development version. Cisco also states that there is not information yet from their development team about when a fix for this vulnerability will be released. . 2010-11-09: Core replies offering more technical details about exploitation if they are needed, and reminding Cisco that the crash in their development version may also be exploitable even if the current proof of concept exploit only crashes it. The publication date for this advisory is rescheduled to November 22nd 2010. Core states that they will like to schedule a firm date for the release of information about this vulnerability to the public and hence would like to get more information from Cisco about the schedule for the release of a fix. . 2010-11-15: Cisco states that fixed code will be deployed in mid-December, but since WebEx Meeting Center runs on a SaaS environment it takes about four or five weeks for all clients to be running the latest version of the code. . 2010-12-06: Cisco contacts Core since no reply was received in the past two weeks, and clarifies that a fix will be deployed on December 15th and should be done on January 11th 2011. . 2010-12-06: Core states that they believe this advisory should be released as soon as the fix is deployed, since diffing the WebEx binary on the client side gives full details about the WebEx Meeting Center vulnerability to an average skilled reverse engineer. Core schedules the publication of this advisory to December 15th 2010. . 2010-12-07: Cisco contacts Core stating that releasing details about this vulnerability would endanger customers, since there is no action they can take to protect themselves because the responsibility of upgrading the code ran by the customer falls on Cisco. Cisco mentions that "many of these customers are probably shared between Cisco and Core Security". . 2010-12-10: Cisco contacts Core stating that they have just discovered the WebEx Meeting Center Vulnerability affects a new set of customers that where not accounted for originally. These are customers running T27SP21 that can not be upgraded to SP22. An emergency patch will be released for SP21 in January 2011, and this sets back the date when all clients should be running an updated version to the "end of January, beginning of February." . 2010-12-14: Core proposes to split this advisory into two different advisories to better accommodate the WebEx Meeting Center SaaS release cycle. On one advisory, the .wrf client side vulnerability would be described, and the other would be dedicated to the WebEx Meeting Center vulnerability that may compromise a meeting's host computer. Core believes this mitigates the risk in a more effective way, since clients can update WebEx Player by themselves on December 15th (the date when Cisco stated the fixed version would be released) and no details of the Meeting Center vulnerability would be released until all clients are running an updated version. . 2010-12-15: Cisco states they wouldn't like the advisory to be splitted, and that they prefer Core Security Technologies to go ahead and release information about both vulnerabilities. . 2010-12-15: Core states that they prefer to release two advisories because these are two different bugs, in two pieces of software, each one of them with a differently working update channel determined by the vendor. Core also informs Cisco that the download link for WebEx Player points to a vulnerable version as of today, and asks Cisco to clarify what date they meant as mid-December, since Core would like to know when a fixed version of WebEx Player will be available for download to be able to publish the WebEx Player vulnerability. . 2010-12-16: Cisco replies saying that releasing two advisories seems like a good plan to them. Cisco also states that since many of their customers observe a lockdown policy during the holidays season, they take a "don't upgrade" policy of their own until Monday January 10th, 2011. That is the reason why the download link of WebEx Player has not been changed yet. . 2011-01-10: Core states that they are ready to release this advisory on January 11th, and that releasing two separate advisories seems pointless now because the release date of both would be very similar, and the original idea was to mitigate the risk posed by the .wrf vulnerability. Core also states that they are reviewing the best course of action to take with the issue regarding clients running the old version of WebEx (T27SP21) that according to Cisco are unable to upgrade to SP22 since this was not accounted for previously. . 2011-01-13: Core states that since they have committed previously to release the advisory taking into account Cisco's consideration about their SaaS patch deploy model, when factoring the issue of clients running the SP21 version of Meeting Center scheduled by Cisco for emergency update on January, a release date of January the 31st seems reasonable. This date should be taken as final and Core Security Technologies believes it takes into account all information given by Cisco about SaaS updating timeframes. If this is not the case Cisco is asked to rectify ASAP. . 2011-01-14: Cisco confirms that the timeframe (publishing both vulnerabilities on January 31st) works for them. . 2011-01-31: The advisory CORE-2010-1001 is published. 10. *References* [1] [http://www.webex.com/] [2] [http://corelabs.coresecurity.com/index.php?module=Wiki&action=view&type =project&name=Bugweek] 11. *About CoreLabs* CoreLabs, the research center of Core Security Technologies, is charged with anticipating the future needs and requirements for information security technologies. We conduct our research in several important areas of computer security including system vulnerabilities, cyber attack planning and simulation, source code auditing, and cryptography. Our results include problem formalization, identification of vulnerabilities, novel solutions and prototypes for new technologies. CoreLabs regularly publishes security advisories, technical papers, project information and shared software tools for public use at: [http://corelabs.coresecurity.com]. 12. *About Core Security Technologies* Core Security Technologies develops strategic solutions that help security-conscious organizations worldwide develop and maintain a proactive process for securing their networks. The company's flagship product, CORE IMPACT, is the most comprehensive product for performing enterprise security assurance testing. CORE IMPACT evaluates network, endpoint and end-user vulnerabilities and identifies what resources are exposed. It enables organizations to determine if current security investments are detecting and preventing attacks. Core Security Technologies augments its leading technology solution with world-class security consulting services, including penetration testing and software security auditing. Based in Boston, MA and Buenos Aires, Argentina, Core Security Technologies can be reached at 617-399-6980 or on the Web at [http://www.coresecurity.com]. 13. *Disclaimer* The contents of this advisory are copyright (c) 2011 Core Security Technologies and (c) 2011 CoreLabs, and are licensed under a Creative Commons Attribution Non-Commercial Share-Alike 3.0 (United States) License: [http://creativecommons.org/licenses/by-nc-sa/3.0/us/] 14. *PGP/GPG Keys* This advisory has been signed with the GPG key of Core Security Technologies advisories team, which is available for download at [http://www.coresecurity.com/files/attachments/core_security_advisories. asc]. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAk1HJwcACgkQyNibggitWa13VwCfVg6jVkuv3PhqmhNqZFIQO7CB L1YAni1ONdRqEYczbkvki9r0Y7nr9cIQ =9HdA -----END PGP SIGNATURE-----