how can a Java buffer overflow lead to arbitrary code execution?

[neuneudr]

Hi,

there's something I don't get about a recent Java GIF decoder exploit.

I was under the impression that since Java existed there had never
been any
buffer overrun/overflow in Java programs. That the JVM explicitely
made that
impossible and that, should a buffer overflow happen, it would an
error in
the implementation of the particular JVM it'd affect, not a flaw in
the JVM sandbox
model.

Now I know we've already seen some issues (I remember, for example,
some
zlib decompression exploit, but it was a third-party, native C lib
that the JVM
depended on).

Here's the issue (it clearly says that it's a "buffer overrun") :

"Security Vulnerability in Processing GIF Images in the Java Runtime
Environment
May Allow an Untrusted Applet to Elevate Privileges"

http://www.sunsolve.sun.com/search/document.do?assetkey=1-26-102760-1

Does it mean that the GIF decoder is not written in Java ?

If the GIF decoder is written in Java, how can a buffer overrun
happen ?
(does it mean the sandbox model, which has been free of buffer overrun
since 10 years, is broken?)

Thanks in advance to anyone shedding light on this,

Driss

 

[Daniel Pitts]

Hi,

there's something I don't get about a recent Java GIF decoder exploit.

I was under the impression that since Java existed there had never
been any
buffer overrun/overflow in Java programs. That the JVM explicitely
made that
impossible and that, should a buffer overflow happen, it would an
error in
the implementation of the particular JVM it'd affect, not a flaw in
the JVM sandbox
model.

Now I know we've already seen some issues (I remember, for example,
some
zlib decompression exploit, but it was a third-party, native C lib
that the JVM
depended on).

Here's the issue (it clearly says that it's a "buffer overrun") :

"Security Vulnerability in Processing GIF Images in the Java Runtime
Environment
May Allow an Untrusted Applet to Elevate Privileges"

http://www.sunsolve.sun.com/search/document.do?assetkey=1-26-102760-1

Does it mean that the GIF decoder is not written in Java ?

If the GIF decoder is written in Java, how can a buffer overrun
happen ?
(does it mean the sandbox model, which has been free of buffer overrun
since 10 years, is broken?)

Thanks in advance to anyone shedding light on this,

Driss

It could be that more recent versions (the site you gave will tell you
what is effected) use native code to handle the (de)compression of GIF
files. Native code is exempt from most of Java's safeguards.

 

[Chris Uppal]

"Security Vulnerability in Processing GIF Images in the Java Runtime
Environment
May Allow an Untrusted Applet to Elevate Privileges"

http://www.sunsolve.sun.com/search/document.do?assetkey=1-26-102760-1

Does it mean that the GIF decoder is not written in Java ?

Like Daniel, I assume that the GIF decoder is actually written in something
like C, and invoked via JNI.

What bothers me about the security announcement is that it suggests that the
impact is limited to allowing applets to escape the sandbox. Unless there's
something about the problem that they are not mentioning, then it's a good deal
worse than that: it makes /any/ Java application which displays GIFs
potentially vulnerable to arbitrary code execution.

Ones that use Sun's decoder, anyway. And only ones that display, or can be
tricked into displaying, a maliciously-crafted GIF.

For instance (purely imaginary). A chat application which allows people to
send GIFs to each other to be used as "faces". Or another application which
uses downloadable "skins". Or an image catalogue program written in Java....


There's a better description of it here:
http://www.zerodayinitiative.com/advisories/ZDI-07-005.html
Although that also seems to underestimate the scope somewhat.

-- chris