[NEWS] Workaround Addresses JRun Server SSIFilter Security Issue

From: support@securiteam.com
Date: 12/11/01 

From: support@securiteam.com
To: list@securiteam.com
Date: Tue, 11 Dec 2001 09:04:55 +0100 (CET)

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -

  Workaround Addresses JRun Server SSIFilter Security Issue
------------------------------------------------------------------------

SUMMARY

Accessing files through the SSIFilter with a low-level tool such as telnet
and netcat allows you to issue HTTP commands that can expose contents of
jsp files and or other files that should not be accessible.

DETAILS

Affected software versions:
 * JRun 3.1 (all editions)
 * JRun 3.0 (all editions)
 * JRun 2.3.3 (all editions)

The problem described in this bulletin exists in JRun 3.1, 3.0 and 2.3.3
and only occurs when going through a commercial webserver after having
installed a connector. This has been tested with IIS 5.0, Apache 1.3.22
and iPlanet 4.1 on Win2K and Solaris. The problem does not occur when
going through the JRun Web Server (JWS). The vulnerability can be exposed
in two different ways. First, the problem occurs by issuing an HTTP GET
(or PUT, POST, OPTIONS, HEAD, DELETE, CONNECT) statement of a non-existent
shtml file followed by a "Content-Length" header and a #include you might
use in an actual .shtml file. If the #include points to an actually jsp in
your web directory structure including the WEB-INF directory (in the 3.x
versions), you will actually see the contents of the file in the #include.
The second way in which this occurs is similar to above. Instead of doing
a GET on a non-existent shtml file, you can replace this with a GET on
/servlet/allaire.jrun.ssi.!

Workaround:
For JRun 3.1 and 3.0 you should remove the following line from the
/jrun/lib/global.properties file in the rules section:

webapp.servlet-mapping.*.shtml=ssifilter

You should then add the following line to the jrun/lib/global.properties
file in the rules section:

webapp.servlet-mapping./servlet/allaire.jrun.ssi.SSIFilter=xxx

For JRun 2.3.3 you can use the JRun 2.3.3 Administrator to remove the
shtml mapping. Listed below is what you will need to do.

1) Start the 2.3.3 Administrator
2) Highlight the row that begins with "jsm-default"
3) Click on the "Configure" button
4) Highlight the row that begins with "jse"
5) Click on the "Service Config" button
6) Click on the "Mappings" tab
7) Highlight the row that begins with "*.shtml"
8) Click on the "Delete" button
9) Click on the "Save" button
10) Repeat steps 1-9, replacing "jse" with "jseweb" in step 4

For JRun 2.3.3 you can use the JRun 2.3.3 Administrator to add a "dummy"
mapping for /servlet/com.livesoftware.jrun.plugins.ssi.SSIFilter . Listed
below is what you will need to do.

1) Start the 2.3.3 Administrator
2) Highlight the row that begins with "jsm-default"
3) Click on the "Configure" button
4) Highlight the row that begins with "jse"
5) Click on the "Service Config" button
6) Click on the "Mappings" tab
7) Click the "Add" button
8) In the new "Virtual Path/Extension" field, type
"/servlet/com.livesoftware.jrun.plugins.ssi.SSIFilter"
9) In the "Servlet Invoked" field next to it, type "xxx"
10) Click the "Save" button
11) Repeat steps 1-9, replacing "jse" with "jseweb" in step 4

These workarounds will safeguard you against this vulnerability. You will
have to restart your server(s) after you do this. In the case of 2.3.3 you
should also stop and start your web server, also.

What Macromedia is doing:
Macromedia has published this bulletin, notifying customers of the
problem. Macromedia has also released this workaround for versions 3.1,
3.0 and 2.3.3 which prevents using non-existent *.shtml files or calling
the SSIFilter class directly to potentially view the contents of files in
your web applications. A permanent fix to this vulnerability will be made
in a future release of the product.

What customers should do:
Macromedia strongly encourages customers to implement this workaround
immediately.

Please note: As always, customers should test changes in a testing
environment before modifying production servers.

ADDITIONAL INFORMATION

The information has been provided by <mailto:newsflash@macromedia.com>
Macromedia Security Alert.

========================================

This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

====================
====================

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.