|
|
|
|
| |
| 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. |
| |
Credit:
The information has been provided by Macromedia Security Alert.
|
| |
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.
|
|
|
|
|
|
|
|
|
|
