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

2007-05-14T00:00:00
ID SECURITYVULNS:DOC:17009
Type securityvulns
Reporter Securityvulns
Modified 2007-05-14T00:00:00

Description

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

  1. January 2007 - Notified vendor of affected software
  2. January 2007 - Vulnerability confirmed
  3. May 2007 - Release of patch
  4. May 2007 - Public disclosure

Regards, Michael Domberg, www.devtarget.org