-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Holy shit, your timeline has more entries than Anne Frank's diary!
On Tue, 25 Sep 2007 12:20:55 -0400 Core Security Technologies Advisories <[EMAIL PROTECTED]> wrote: >Core Security Technologies – CoreLabs Advisory > http://www.coresecurity.com/corelabs > >Remote command execution, HTML and JavaScript injection >vulnerabilities in >AOL’s Instant Messaging software > >*Advisory Information* > >Title: Remote Command execution, HTML and JavaScript injection >vulnerabilities in AOL's Instant Messaging software > >Advisory ID: CORE-2007-0817 > >Advisory URL: >http://www.coresecurity.com/index.php5?module=ContentMod&action=ite >m&id=1924 > >Date published: 2009-09-25 >Date of last update: 2007-09-25 >Vendors contacted: AOL LLC. > >Release mode: Forced Release > >*Vulnerability Information* > >Class: Design Error >Remotely Exploitable: Yes >Locally Exploitable: No >Bugtraq ID: 25659 >CVE Name: CVE-2007-4901 > >*Vulnerability Description* > >AOL Instant Messenger ("AIM", http://www.aim.com) is an instant >messaging >application that allows its users to communicate in real time via >text, >voice, and video over the Internet. It is maintained by AOL LLC. >AIM Pro >is AOL's business-oriented version of AIM targeted for >professional use >with an emphasis on "business-grade" security and integration with >email >client and other productivity applications >(http://aimpro.premiumservices.aol.com/) AIM Lite, as defined in >its >website (http://x.aim.com/laim/), is a reference application used >to test >new technology also developed by AOL and available for the public >in the >form of a "light IM client". > >A vulnerability was discovered in these three popular versions of >AOL >Instant Messaging software, AIM 6.1 (and 6.2 beta), AIM Pro and >AIM Lite, >which expose workstations running the IM clients and their users >to >several immediate high-risk attack vectors. To support rendering >of HTML >content, the vulnerable IM clients use an embedded Internet >Explorer >server control. Unfortunately they do not properly sanitize the >potentially malicious input content to be rendered and, as a >result, an >attacker might provide malicious HTML content as part of an IM >message to >directly exploit Internet Explorer bugs or to target IE‟s security >configuration weaknesses. > >In particular this attack vector exposes workstations to: >- Direct remote execution of arbitrary commands without user >interaction. >- Direct exploitation of IE bugs without user interaction. For >example, > exploitation bugs that normally require the user to click on a >URL > provided by the attacker can be exploited directly using this >attack > vector. >- Direct injection of scripting code in Internet Explorer. For >example, > remotely injecting JavaScript code into the embedded IE control >of the > AIM client. >- Remote instantiation of Active X controls in the corresponding >security > zone. >- Cross-site request forgery and token/cookie manipulation using >embedded > HTML. > >*Vulnerable packages* > AIM 6.1 (6.1.41.2) > AIM 6.2 (6.2.32.1) > AIM Pro > AIM Lite > >*Non-vulnerable packages* > AIM 6.5 (6.5.3.12) - >http://beta.aol.com/projects.php?project=aim6 > AIM Express - http://www.aim.com/aimexpress.adp > Classic AIM 5.9 - http://www.aim.com/get_aim/win/other_win.adp > >*Vendor Information, Solutions and Workarounds* > >AOL LLC Vendor Statement; > >Overview >AOL has become aware of security vulnerabilities in several AIM >instant >messaging clients. Successful exploitation of these >vulnerabilities could >allow an attacker to execute arbitrary commands on a user's >workstation. >AOL has deployed host side filtering on the AIM servers to block >this >potentially malicious content from being sent to AIM clients. > >Affected Products and Applications >* AIM 6.1 >* AIM 6.2 >* AIM Pro >* AIM Lite > >Solutions >1. Users of AIM can upgrade to the latest version of the AIM beta >client >at beta.aol.com. > >Acknowledgments >AOL would like to thank Core Security Technologies for responsibly >reporting this issue to AOL and for working with AOL on testing >and >mitigating these issues. > >*Other workarounds (un-official)* >Workaround #1: Users running AIM on Microsoft Windows XP SP2 or >Windows >Server 2003 SP1 may implement Microsoft's "Internet Explorer Local >Machine >Zone Lockdown" recommendations to mitigate risk. This will not fix >the >reported bugs but will reduce the risk of exploitation >significantly. >To enable Local Machine Zone Lockdown for your AIM client, go to >the >following registry key: > >HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft \Internet >Explorer\Main\FeatureControl\FEATURE_LocalMachine_Lockdown > >Add a REG_DWORD value to this key named as the AIM client >application (for >example, aim.exe) and set it to 1. Any other setting for this >value will >disable Local Machine Zone Lockdown for the application. > >For further details about how to configure this feature read >Microsoft‟s >Internet Explorer Local Machine Zone Lockdown recommendation at: >http://technet.microsoft.com/enus/library/bb457150.aspx#EHAA > >*Credits* >This vulnerability was discovered by Lucas Lavarello from the CORE >Security Consulting Services (CORE SCS) team. > >*Technical Description / Proof of Concept Code* > >The standard protocol that AIM clients use to communicate is >called OSCAR >(Open System for CommunicAtion in Realtime), which is a closed >protocol >also used by AOL's secondary Instant Messaging client, ICQ (I Seek >You). >On top of the OSCAR protocol, AIM clients have implemented support >for >enhanced message types that use features provided by the HTML >(Hyper Text >Markup Language) in order to, for example, provide AIM users with >the >possibility of exchanging text messages with specific font formats >or >colors. AIM 6.1, AIM 6.2 (beta), AIM Pro and AIM Lite have >embedded an >Internet Explorer server control in the message display window in >order to >facilitate the parsing and displaying of HTML controls. It is a >common >practice for Windows applications to reuse Microsoft Internet >Explorer‟s >HTML parsing objects included in the mshtml.dll library instead of >using a >homebrew HTML parser. Several programming frameworks, including >MFC >(Microsoft Foundation Classes), provide practical ways of >embedding such >controls through classes like CHtmlEditView or CHtmlEditDoc. >Some of the advantages of using MSHTML are that it provides a >particular, >feature-rich and somewhat complete support for DHTML and also that >it is >easier to host Microsoft ActiveX Controls. However, in the context >of this >advisory, such advantages may end up becoming security problems >due to >design flaws and implementation bugs. >There are two particular characteristics in the implementation of >the >described functionality that turn AIM‟s highly flexible message- >content >features into high-risk attack vectors for its users. > >First, the vulnerable IM clients do most of the >sanitizing/filtering and >encoding of HTML content on outbound messages, thus a malicious >attacker >with the ability to bypass outbound HTML filtering can send any >type of >HTML content to other IM clients. >A handful of publicly available and well-known IM clients permit >to send >un-sanitized data to any other client that supports the same >communications protocol including the vulnerable AIM 6.1, AIM 6.2, >AIM Pro >and AIM Lite clients. >Second, although there are some defensive mechanisms implemented >in the >vulnerable clients these are insufficient to properly handle >messages with >potentially malicious content. Input validation of inbound >messages >appears to be taking place but can be easily circumvented by an >attacker. >As a result, the entire attack surface of MSHTML is exposed to >remote IM >peers. By having a way of sending data straight to the MSHTML >library, >attackers could abuse such high-risk attack vector to: > >- Execute arbitrary shell commands in the victim‟s workstation. >- Direct the embedded IE to perform arbitrary HTTP requests (CSRF) >- Include HTML controls (links, images, forms…) in IM text >messages in > order to trick users into revealing sensitive information or >performing > harmful actions against their accounts/workstation/etc. >- Run JavaScript code within IE to enhance the attacks mentioned >above. >- Instantiate ActiveX controls, which attackers could use to >target > vulnerabilities in the ActiveX objects themselves or use their > functionality to, for example, read arbitrary files from the >victim's > file system or even execute arbitrary shell commands in the >victim's > workstation. >- Directly attack vulnerable versions of Internet Explorer in user > workstations. This is a typical client-side attack scenario and >could > lead to the remote execution of arbitrary code in the victim's > workstation. In this scenario "one-click" IE bugs (exploitation >requires > user assistance) become "zero-click" bugs (exploitation does not >require > user interaction). > >AOL's "Classic AIM 5.9" is an official alternative client for >nostalgic >users and is not vulnerable due to the fact that instead of using >MSHTML >to render HTML it appears to include limited rendering >functionality >either provided by a third party library or homebrew code. >Although there >is no guarantee that its implementation lacks vulnerabilities, in >our >tests it did prevent the attack vectors described in this >advisory. So >is the case for AOL‟s AOL 6.5.3.12 which although it is embedding >an >Internet Explorer server control in the message window, could not >be >exploited during our tests. >AOL's online AIM Express web client which is written in ASP.NET >and also >appears to be taking the necessary defensive measures required to >prevent >any of these problems from taking place. > >*Proof of concept snippets* >The following examples provide code snippets that should serve as >proof-of-concept code to demonstrate some of the problems that >arise from >the issue reported. The snippets have been arranged according to >their >risk level, in increasing order (lower risk first), with the >intention of making this process more self-explanatory. In order >for these >snippets to work, they must be sent within the contents of a >standard >instant message, but using a client that will not encode message >contents >on output: > >*Using HTML controls in order to trick victims into revealing >sensitive >information or do harmful actions against their >accounts/workstations or >to force outbound HTTP requests (CSRF).* > >The following proof-of-concept code was successfully tested on AIM >Pro. >Other vulnerable clients need some tweaking in order to get it to >work. >The code uses <hr>, <h2>, <form> and <input> tags to trick the >victim into >believing that an AIM disconnection took place. It then requests >the >victim to type in the user credentials and to press the Reconnect >(submit) >button in order to send the credentials to the attacker. In this >case, the form is submitted to "http://localhost"; > > >--- begin code --- ><hr><h2>SERVICE UNAVAILABLE</h2><hr>Your connection to AIM has >been >interrupted. Please type in your credentials in order to >reconnect. Thank >you.<br><form method=GET action=http://localhost>Login: <input >type=text >name=login><br>Password: <input type=text name=password><br><input >type=submit value=Reconnect></form><br><hr> >--- end code --- > > >This is simply one example of exploitation using only embedded >HTML. There >are plenty of HTML controls that could be used in similar >exploitation >scenarios. > >*Using scripting languages to enhance an attack* > >As mentioned in the beginning of the technical details section, we >identified among all the vulnerable clients what appeared to be an >existing defensive measure (or a functional characteristic with a >side-effect) meant to prevent attackers from inserting malicious >JavaScript statements within message contents. When sending >JavaScript >statements inside <script> tags within a message, the script tags >appear to be filtered by the receiving client upon display >(therefore not >executing the JavaScript statements). However, this was easily >circumvented by embedding JavaScript statements inside <img> tags, >as in >the following example: > >The following code does not work: ><script>alert(‘I have executed javascript in your >computer’)</script> > >The following code *does* work: ><img src="javascript:alert(‘I have executed javascript in your >computer’)"> > >Note that even though the different proof-of-concept snippets >provided in >this advisory use <img> tags to execute JavaScript, the problem >must not >be thought of as circumscribed to message contents with embedded ><img> >tags only. JavaScript statements may also be executed through the >use of >other HTML controls and some of the attack vectors that we mention >do not >even rely on JavaScript for successful exploitation. >The following proof-of-concept code will display a prompt box to >the >victim, requesting to type in the victim's AIM credentials. It >will look >authentic due to the fact that the message box is not part of the >text >message window: > >-- begin code -- ><img src='javascript:var passwd=window.prompt("You have been >disconnected from the network.\nPlease re-enter your password to >reconnect.", "");alert(“You have disclosed your >password:”+passwd);'> >-- end code -- > >Once the victim types-in her/his password, an alert message box >will be >displayed showing the entered password. Attackers could easily >retrieve >passwords and other security-sensitive data by using the same >techniques >used to exploit Cross Site Scripting vulnerabilities to steal >browser cookies. > >*Instantiating ActiveX controls and taking over the victim’s >workstation* > >Another way of enhancing an attack could rely on using ActiveX >controls >installed on the target system. For that, the attacker needs the >ability >to instantiate arbitrary ActiveX controls using an IM message >content >constructed to accomplish such purpose. We successfully used this >attack >vector in AIM 6.1, AIM 6.2beta and AIM Lite in order to get >immediate and >instant access to the victim‟s workstation. This attack vector >increases >considerably the severity of the problems found, turning the >affected >clients into a doorway to the user‟s computer and ultimately >providing >attackers with ways of executing arbitrary commands. >Apparently, AIM Pro is the only client that runs the Internet >Explorer >server control in a "protected" security zone, where the victim is >prompted with the typical message box that says: > >"An ActiveX control on this page might be unsafe to interact with >other >parts of the page. Do you want to allow this interaction?" > >The choice of the user will affect the entire instance of the >application >and be applied to any other existing/future message windows (as >well as >potentially any other locations where the Internet Explorer server >control is used.) > >Attackers could use JavaScript to instantiate ActiveX controls in >order to >either exploit client-side vulnerabilities of the ActiveX objects >themselves or to use ActiveX functionality as an aid to exploit >other bugs.. >As the following proof-of-concept snippet shows, an attacker can >successfully instantiate the "Shell.Application" object that is >included >in the Microsoft Windows OS installation and use it to execute any >arbitrary command on the victim‟s workstation. > >As previously mentioned, in three of the four affected versions of >the >product, the attack is straight forward and no interaction with >the victim >is required. Such clients appear to be running Internet Explorer >control >in the Local Machine Security Zone. > >-- begin code -- ><img src="javascript:var oShell = new >ActiveXObject('Shell.Application');oShell.ShellExecute('cmd.exe', >'/c >pause');"> >-- end code -- > >The proof-of-concept code from above will run an instance of >Microsoft >Windows command line tool, executing the pause command. Upon >receipt, it >will instantly show a blank command window in the victim‟s >workstation. An >attacker may easily abuse this issue to gain complete control over >the >victim‟s machine with the privileges of the user running AIM. > >*Attacking vulnerable versions of Internet Explorer controls* >This scenario is just a clear-cut client-side attack vector and >would rely >on any unpatched security vulnerability in Internet Explorer or >the >ActiveX controls it hosts. An embedded HTML URI can direct the IE >server >control to automatically visit a previously setup site that >delivers >malicious content to exploit known Internet Explorer >vulnerabilities. In >this case, the AIM clients identified as vulnerable in this >advisory play >the role of exposing their users to attacks without requiring user >intervention to allow/disallow access to the rogue website. This >attack >scenario is functionally equivalent to a user of Internet Explorer >clicking on a URL and visiting a malicious site. > >*Additional Information and resources* > >AOL’s AIM clients > AIM Pro: http://aimpro.premiumservices.aol.com/ > AIM 6.2: http://beta.aol.com/projects.php?project=aim6 > AIM 6.1: http://www.aim.com/get_aim/win/latest_win.adp > AIM Lite: http://x.aim.com/laim/ > AIM 5.9: http://www.aim.com/get_aim/win/other_win.adp > AIM 6.5: http://beta.aol.com/projects.php?project=aim6 > >Embedding IE > Introduction to ActiveX Controls: > http://msdn2.microsoft.com/en-us/library/aa751972.aspx > > Reusing MSHTML: > http://msdn2.microsoft.com/en-us/library/bb508516.aspx > > Internet Explorer Local Machine Zone Lockdown > http://technet.microsoft.com/en-us/library/bb457150.aspx#EHAA >http://technet2.microsoft.com/windowsserver/en/library/aebcfc94- >25d5-4f41-93cc-7fb6e031de401033.mspx?mfr=true > >About URL Security Zones > http://msdn2.microsoft.com/en-us/library/ms537183.aspx > >*Report Timeline* > >*2007-08-21*: Initial report to AOL Product Vulnerabilities Team >(PVT) >requesting acknowledgement within 2 business days, advisory >publication >date tentatively set to September 24th. >*2007-08-22*: Received an acknowledgement and PGP public key from >AOL's >PVT. AOL's PVT indicates that upon reception of vulnerability >details and >bug confirmation, expectations should be to allow for two business >weeks >for an estimated timeline to resolution. Core's PGP/GPG key >requested. >*2007-08-23*: Draft advisory and GPG public key sent to AOL's PVT. >*2007-08-31*: Acknowledgement from AOL confirming the existence of >the >vulnerabilities in AOL's IM clients. AOL indicates that the >development >and QA teams are working on fixes with an estimated release >scheduled for >mid-October. Additionally, note that one of the IM clients >requires >coordination with a third-party. >*2007-09-04*: Reply from Core, acknowledging the previous email >from AOL >PVT. Release date for the advisory set to October 16th in >accordance to >AOLs estimation. Core indicates that there is no indication of >exploitation "in the wild" but that these bugs are considered >extremely >critical due to the simple way they can be found and exploited and >the >large population of vulnerable systems. >*2007-09-10*: Email from the AOL PVT indicating that the bugs are >considered extremely critical by AOL as well and expressing their >intention to provide weekly status updates. An estimated date for >fixes >will be forthcoming as soon as they have one. In the meantime, a >server-side mitigation mechanism has been deployed and Core is >invited to >test it. >*2007-09-10*: Core acknowledges reception of AOL‟s last email. >We‟ve taken >up the offer to test the mitigation mechanism and although it did >prevent >the original proof-of-concept code snippets from working we found >that >attacks are still possible with minor tweaks to the original code. >Tests >were performed using only one of the 4 vulnerable clients, the >others are deemed equally vulnerable. >*2007-09-12*: Core email to AOL notifying them that information >about the >bug may have been disclosed to public security mailing lists by an >unknown >third-party [1]. Precise technical details were not given and >therefore it >is difficult to assess if the bug disclosed by the third-party is >directly >related to those reported by Core. There are still no indications >of >exploitation of these bugs "in the wild". Nonetheless, it is >reasonable to >think that the independent discovery and exploitation of the bugs >reported >by Core is now imminent, should that happen, Core‟s security >advisory will >be published the upcoming week (tentatively Monday Sept. 17th >2007) as a >Forced Release. >*2007-09-14*: Email from AOL PVT indicating that AOL is in >correspondence >with the third-party and received additional information about the >bug, >leading the AOL team to think that the publicly disclosed >vulnerability is >not similar in nature to those reported by Core. The public >vulnerability >will be fixed in the AIM clients in mid-October. AOL's PVT does >not feel >that this public disclosure warrants disclosure of Core‟s >advisory. The >team could not verify that the mitigation mechanism deployed on >the server >can still be bypassed as indicated by Core in a previous email. >The team >requests the exact version numbers of the AIM clients used, proof >of >concept code and/or a description of how to reproduce the test. >*2007-09-14*: Email sent to AOL indicating that a second post with >additional information about the bug has been made by the third- >party [2]. >Core requests further details about this publicly disclosed bug >and asks >AOL to provide the analysis that lead the AOL team to conclude >that it is >of a different nature of those reported by Core. This email >includes >detailed step-by-step instructions on how to bypass the server- >side >filtering mechanism accompanied with the exact version number of >the AIM >client used (6.1.41.2) and the sample code. Core's own analysis of >current >publicly available information indicates that the bug is indeed of >similar >nature than those reported in Core‟s advisory and that active >exploitation >of the bug is likely to happen in a matter of days (not several >weeks). >Thus, in accordance to Core‟s analysis the most responsible course >of >action is to clarify the nature of the AIM problems and provide >the >vulnerable users with enough information to assess and mitigate >the risk. >Baring any further indication from AOL to support the theory of >these >being bugs of different nature, Core will be ready to publish its >security >advisory the week of Sept. 17th to 21st. >*2007-09-18*: Email sent to AOL PVT indicating that Core now >considers the >information about the reported bugs to be publicly available. The >fact >that the third-party reporters did not find (or did not publish) a >way to >exploit it remotely in a more reliable manner does not prevent >others from >doing so. Core‟s team believes that the publicly available >information >about this bug is confusing and does not help vulnerable users >understand >the risks they are exposed to. Therefore, unless AOL provides new >information or analysis to change Core‟s analysis, Core will >publish the >security advisory to provide vulnerable users with the details >needed to >assess risk and devise their own mitigation mechanisms until >official >fixed versions of the clients are made available. >*2007-09-19*: Email sent to AOL indicating that information about >the >reported vulnerabilities is now part of Mitre CVE dictionary, the >US >National Vulnerability Database [3], the Securityfocus.com >vulnerability >Database [4] and the Secunia.com website [5], therefore Core >considers >that any security-aware party (either good or bad intended) can >now easily >figure out a remote exploitation method. In fact, several messages >in >AOL's technical forums seem to indicate that users of AIM clients >are >experiencing AIM "bugs" or "problems" related to the issues >reported in >Core‟s advisory [6],[7] and that AOL itself seems to be using >HTML/JavaScript injection and instantiation of third-party ActiveX >controls [8]. Therefore, to provide accurate information that >helps >security practitioners understand the risks and devise mitigation >strategies for affected end users and organizations Core has >decided to >release this security advisory on Monday Sept. 24th. AOL‟s >statement >regarding release of fixed clients and any other mitigation >mechanism is >expected by COB Friday Sept. 21st. In the meantime, Core >researchers will >try to find suitable workarounds to prevent exploitation. >*2007-09-20*: Email from AOL PVT indicating that the bug posted >publicly >is different than those reported by Core because it “is based upon >another >application within the AIM client that allows a limited number of >characters that can be put into a alert message within a script >tag, >"<script>alert("Test")</script>". This message will only work when >sending a IM to someone who is using one of the AIM 6.x clients >and does >not have the sender focused within their AIM client. When sending >a >message to an AIM user who does not have the sender focused in >their AIM >client, a notification window will pop up informing the recipient >that >they have just received a message from another AIM user. It is >this >application in the AIM 6.x clients that is not properly parsing >the >messages for this type of html tag and pop's up an alert window.” >The >other public problems pointed out by Core posted in AOL‟s message >boards >are not caused by AIM clients. AIM client 6.5.3.12 (currently in >Beta) >fixes the reported problems and is available for public download >(and for >testing). AOL remains unsuccessful trying to verify that the >serverside >filtering mechanism can be bypassed and requests additional data >(exact >version numbers of the IE on the target system and AIM clients >used). AOL >requests to delay publication of the security advisory until the >date >previously agreed on (October 16th, 2007) the release of fixes is >still on >schedule for mid-October. >*2007-09-20*: Email sent to AOL PVT stating that Core‟s analysis >indicates >that the publicly disclosed bug and those reported by Core are of >the same >and that in fact the public one is just a trivial variation of one >of the >attack scenarios explicitly described by Core. Further details >provided >about how to test AOL‟s server-side filtering mechanism (although >we don‟t >think the versions of IE and AIM on the source and target system >are >relevant to test server-side filtering). Core points out that the >messages >on AOL's message boards disclose specific non-malicious HTML code >that is >currently being injected into clients, including JavaScript and >instantiation of ActiveX controls and that should be considered >directly >related to the bugs reported because they demonstrate that >arbitrary HTML >content can be injected into AIM. Core has confirmed that AIM >6.5.3.12 is >not vulnerable to attack (although extensive regression testing of >all >possible attack patterns was not performed). >Given all the publicly known facts Core deems active exploitation >imminent >and therefore still plans to release the security advisory on >Monday Sept. >24th in order to provide precise details to help users become >aware of the >risk they are exposed to and to deploy countermeasures to prevent >active >exploitation. >*2007-09-21*: Email received from AOL PVT requesting a conference >call to >discuss the issues reported and how to handle them. >*2007-09-21*: Conference call between Core Security advisories >team, >Core's bug discoverer and AOL PVT. AOL reported that the current >version >of AIM 6.5 addresses the bugs reported and that AOL could >replicate the >test of the service-side filters and had fixed the bypass. >Availability of >fixed release versions of AIM is still scheduled for mid-October. >Core >reports that AIM v6.5.3.12 indeed seems to have fixed the problem >(although full regression was not performed) and that the publicly >known >information about HTML injection in AIM clients makes it trivial >for >attackers to figure out variations of the published code that can >succeed >against vulnerable systems. Core will re-test the server-side >filtering >mechanism. The final security advisory will be sent to AOL by COB >September Friday 21st and the publication date moved to Tuesday, >September >25th, 2007 to incorporate AOL's official statements regarding >fixes and >mitigation and final rests of the interim server-side filters. The >publication date is final. >*2007-09-21*: Email sent to AOL PVT indicating the server- >filtering has >improved considerably but can still be bypassed. Other variations >of the >same type of attack should be blocked. >*2007-09-21*: Email sent to AOL PVT indicating use of Internet >Explorer >Local Machine Zone Lockdown recommendation may be a suitable >workaround. >*2007-09-24*: Email from AOL PVT including AOL's official >statement >regarding this report (included in the "Vendor Information, >Solutions and >Workarounds" section). >*2007-09-25*: CoreLabs Security Advisory CORE-2007-0817 published > >*References* >[1] AIM Arbitrary HTML Display in Notification Window > shell at dotshell dot net > http://www.securityfocus.com/archive/1/479199 >[2] AIM Local File Display in Notification Window > shell at dotshell dot net > http://www.securityfocus.com/archive/1/479435 >[3] http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-4901 >[4] http://www.securityfocus.com/bid/25659 >[5] http://secunia.com/advisories/26786/ >[6] "AIM 6.1 problems" thread on AOL‟s AIM Support & more >technical forum >http://messageboards.aol.com/aol/en_us/articles.php?boardId=565563&; >articleId=16537 >[7] "IM problems" thread in AOL‟s AIM 6 Technical Issues forum >http://messageboards.aol.com/aol/en_us/articles.php?boardId=565563&; >articleId=16537 >[8] "Copyright and Confidentiality notice?" thread on AOL‟s AIM 6 >Technical Issues forum >http://messageboards.aol.com/aol/en_us/articles.php?boardId=567774&; >articleId=2400 > >*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://www.coresecurity.com/corelabs/ > >*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. 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 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. > >*DISCLAIMER* >The contents of this advisory are copyright (c) 2007 CORE Security >Technologies and (c) 2007 CoreLabs, and may be distributed freely >provided >that no fee is charged for this distribution and proper credit is >given. >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_advisor >ies.asc -----BEGIN PGP SIGNATURE----- Note: This signature can be verified at https://www.hushtools.com/verify Charset: UTF8 Version: Hush 2.5 wpwEAQECAAYFAkb5aNEACgkQ+dWaEhErNvSNGwQAgXk8qK9s5dE4f5yaC6J9KQp2nmvG Rzo/cpjFmG8jTTvlpqpNqJ7rbxkCLkH/LtPuGlMmyoXzdnbgqCHBwvepGBbJKK4Fyxo4 /RQyW9QA7CesVn4Bn6dtnVfyfarRuVT/1uaME+61VU20N87YOBU34EvB0xv8ysKha8Tr n9pFRwQ= =NeE2 -----END PGP SIGNATURE----- -- Click for free info on earning your associates degrees. http://tagline.hushmail.com/fc/Ioyw6h4dDtGq7AhfSJ30O15WhrnEWOddp89PAZBg0Iw1dn6tOtxan2/ _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
