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

Discussion in 'Java' started by neuneudr@yahoo.fr, Feb 2, 2007.

  1. Guest

    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
    , Feb 2, 2007
    #1
    1. Advertising

  2. Daniel Pitts Guest

    On Feb 2, 8:10 am, wrote:
    > 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.
    Daniel Pitts, Feb 2, 2007
    #2
    1. Advertising

  3. Chris Uppal Guest

    wrote:

    > "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
    Chris Uppal, Feb 5, 2007
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Honestmath
    Replies:
    5
    Views:
    549
    Honestmath
    Dec 13, 2004
  2. Replies:
    0
    Views:
    435
  3. Ann
    Replies:
    0
    Views:
    402
  4. Mike Berrow
    Replies:
    4
    Views:
    95
    Mike Berrow
    Jun 22, 2008
  5. Ann
    Replies:
    1
    Views:
    195
    Anthony Levensalor
    Jan 2, 2008
Loading...

Share This Page