Security Advisory: Arbitrary File Access and Denial of Service Vulnerabilities in Business Objects’ Crystal Report Web Delivery Modules


Crystal Reports and Crystal Enterprise are a leading reporting and data presentation solution from Business Objects® (who acquired Business Decisions earlier this year). Both contain components for web delivery of reports, using various common web technologies (ASP, ASP.NET, jsp etc.). Those web presentation components render the requested report into HTML documents delivered to the end user through a web server. Images, especially charts and graphs, included in the report are rendered as temporary PNG files linked to from the HTML document. The temporary PNG files are delivered through a dedicated module upon request from a client (e.g. a web browser) and then deleted.


Imperva's Application Defense Center has conducted research of the widely used Crystal Reports product and had determined that the modules which deliver image files through the web are vulnerable in a way that can be exploited for arbitrary file access and denial of service.

The Findings

While using Crystal Report in a web environment, there are modules for delivering image files (charts, graphs, dynamically chosen pictures, etc.). There is one such module for each prominent web delivery technology (ASP, ASP.NET and jsp). These modules deliver an image file by its name and then remove it from hard disk. An attacker is able to use this module to access arbitrary files on the server and remove them.


  • Arbitrary File Access and Removal

    The web reporting engine of the Crystal Reports package renders a report as an HTML document that contains hyperlinks to images. The images are not accessed directly from the client but rather delivered through a dedicated module (crystalimagehandler.aspx, crystalimagehandler.asp or crystalimagehandler.jsp). This module accepts a single parameter called dynamicimage that specifies the name of a temporary image file created by the rendering engine. The file is delivered to the client and then, by default, removed from the disk. A common request would be similar to the following:

    Which will send the file named 2a7173aa-a2e4-4f96-b9e1-11332c696bbd.png to the requesting client, and delete it.

    The module is susceptible to directory traversal and would deliver any file on the disk that is specified by the parameter dynamiciamge. Hence, if the image files are created in c:\winnt\temp then the following request:\win.ini

    delivers the file win.ini and the following request:\..\boot.ini

    delivers the file boot.ini from the disk’s root directory.

    In addition to delivering the request file which may contain confidential information the module removes the file from the disk. This of course may lead to a denial of service. For example, if win.ini is request through this module it will be removed from the disk and the attacked server will not be able to reboot.

  • Disk Space Exhaustion

    The Crystal Reports web delivery module relies on the image delivery module to both deliver the image file and cleanup the disk space it occupies. Hence, calling the report generation modules repeatedly without retrieving the related images (e.g. by using a Perl script) causes the report engine to take up more and more space in the image file folder. Not only that disk space is consumed quickly but response time for other users become substantially longer as the number of files in the folder increase. Eventually disk space will become exhausted.


The exploit is carried out by simply sending a request URL to the crystal reports server looking like this:

http://foo,bar/crystalreportviewers/crystalimagehandler.aspx?dynamicimage=..\..\..\..\..\my documents\private\passwords.txt


  • Crystal Reports version 9
  • Crystal Enterprise version 9
  • Crystal Reports version 10
  • Crystal Enterprise version 10

Vendor's Response

Business Objects were notified of the vulnerability on April 26th 2004, and acknowledged the vulnerability on May 4th. They published a security bulletin and a patch for the problem on June 8th.


The vulnerability was discovered on April 20th, 2004, by Moran Surf and Amichai Shulman, as part of Imperva's Application Defense Center research activities.

For comments and suggestions please contact


The information within this advisory is subject to change without notice. Use of this information constitutes acceptance for use in an AS IS condition. Any use of this information is at the user’s own risk. There are no warranties, implied or expressed, with regard to this information. In no event shall the author be liable for any direct or indirect damages whatsoever arising out of or in connection with the use or spread of this information.

Redistribution of this alert electronically is allowed as long as it is not edited in any way. To reprint this alert, in whole or in part, in any medium other than electronic medium, for permission.