Closed Bug 378318 Opened 17 years ago Closed 17 years ago

Remote command execution in Java through Firefox

Categories

(Firefox :: Security, defect)

Product:
Firefox
Component:
Security
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: ws, Unassigned)

References

(
URL
)

Details

(Whiteboard: [sg:nse] QuickTime bug, Apple released fix) 

On the mac platform a malicious applet can execute arbitrary commands through a vulnerability in Java.  This was demonstrated as part of a CanSecWest challenge by Dino Dai Zovi.  Dino is obligated to keep the details confidential and we need to work directly with TippingPoint to get details and perhaps a copy of the working exploit. Dino has confirmed that Firefox is only a vector, but we need to consider whether to implement some mitigation.
Is this something specific to the way Gecko interacts with Java, or merely an exploit in the Java plugin on the Mac?
The "[Update: 1:46P EST]" from this bug's URL says "the vulnerability
affects Firefox as well as Safari."

So (fingers crossed) it seems this isn't a hole in the Java Embedding
Plugin.

I've used the Java Embedding Plugin to patch Sun/Apple Java security
holes before, and I could to it again if need be (once we get
sufficient information to reproduce the problem).

By the way, it'd be interesting to know exactly which version of
Firefox (bundling which version of the Java Embedding Plugin) was used
in the demo (and whether their version of OS X was fully patched).
The most recent Firefox releases (2.0.0.3 and 1.5.0.11) bundle JEP
0.9.6.  But JEP 0.9.6.1 (and 0.9.6.2) fully patch a security hole that
Apple has (so far) only partially patched, but which I don't think is
exploitable (with Apple's partial patch).

  https://bugzilla.mozilla.org/attachment.cgi?id=260496 (item #5)
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-﷒0﷓
  http://lists.apple.com/archives/Java-dev/2007/Feb/msg00270.html
  http://lists.apple.com/archives/Java-dev/2007/Feb/msg00277.html

(In reply to comment #1)
> Is this something specific to the way Gecko interacts with Java, or merely an
> exploit in the Java plugin on the Mac?

Dino did not say whether it was in the plugin, the JVM, or somewhere else.  I am pretty sure he was saying it was not in Firefox.  Somewhere in "Java" is all he felt he could confirm since that much had been released publicly anyway.
I talked to David Endler at TippingPoint.  They have to do some contract stuff (obtain disclosure rights) before they can release information to us.  They think tomorrow or Monday at the latest.
(In reply to comment #6)
> Any news?

They are going to give us information at the same time as Apple.  That looks like Monday at this point.
Good.  Thanks.

If this is a LiveConnect hole (or more precisely a hole in the JVM
that only appears when you use LiveConnect), it's likely that I'll
need to do my own patch (in the JEP) ... because (in this case)
Apple's fix is likely to only patch the hole for WebKit clients.

This is part of the response from TippingPoint:

"The vulnerability is actually in qtJava- which is an extension that is added when Quicktime is installed (default on Mac). Firefox and Safari are attack vectors for the vulnerability (and any java-enabled browser)."

They think that because Apple will patch Quicktime that there is no action required from Mozilla.  I am arguing that we do need the details of the vulnerability to determine for ourselves whether in fact there is nothing we need to do here.

If Apple gets a fix out quickly that may be sufficient for our users, but if not , I want us to have the option of protecting Firefox users ourselves.
> I am arguing that we do need the details of the vulnerability to
> determine for ourselves whether in fact there is nothing we need to
> do here.

I agree!

> If Apple gets a fix out quickly that may be sufficient for our
> users, but if not, I want us to have the option of protecting
> Firefox users ourselves.

I think this is wise.  Apple isn't known for the speed of their fixes.
But what I'm most afraid of is Apple releasing a patch that only works
for WebKit clients.

There are couple of mitigating factors, though:  1) QT Java is (I
presume) relatively high-level, which should mean that Apple would
have to work harder to make a patch that's limited to WebKit clients
than to make a "universal" one.  2) It would take some gall for Apple
to release a patch they hadn't tested on Mozilla.org browsers, or
which they knew didn't work on Mozilla.org browsers.

(As it happens, I've never worked with QTJava -- which makes me all
the more eager to see a proof-of-concept and do some testing of my
own.)

TippingPoint agreed and sent us the same advisory they sent to Apple.  Please
let me know if we need any additional information.

-------------BEGIN------------------
ZDI-CAN-190: Apple QTJava toQTPointer() Pointer Arithmetic Memory Overwrite Vulnerability

-- ABSTRACT ------------------------------------------------------------

3Com has identified a vulnerability affecting the following products:

Quicktime for Java 6.1.x

-- VULNERABILITY DETAILS -----------------------------------------------

This vulnerability allows attackers to execute arbitrary code on systems with vulnerable installations of Apple's QuickTime Java extensions. User interaction is required to exploit this vulnerability in that the target must visit a malicious page.

The specific flaw exists within the routine toQTPointer() exposed through quicktime.util.QTHandleRef. A lack of sanity checking on the parameters passed to this routine allows an attacker to write arbitrary values to memory outside of the Java sandbox. This can be leveraged to execute arbitrary code under the context of the current user. Example code execution vectors include both Mozilla Firefox and Apple Safari on both the Mac and Windows operating systems.

The issue stems from the following logic:

    public QTPointerRef toQTPointer (int offset, int size)
    {
        j = j + i <= getSize() ? j : getSize() - i;
        lock();
        return new QTPointerRef(lockAndDeref(i), j, this);
    }

If you call this with 'offset' = 0x7FFFFFFF and 'size' = 0x7FFFFFFF, you get a QTPointerRef that thinks its size is 0x7FFFFFFF, allowing you to use the memory read/write methods to read/write any memory within 0x7FFFFFFF bytes of the QTPointer address. You can get this address by calling QTObject.ID on it. This lets you write anywhere within half of the 32-bit address space. In practice, this covers both the stack and the executable image of the application, which allows us to exploit the vulnerability writing shellcode into the applications __IMPORT section and writing the address of the shellcode over return addresses in the stack segment.

-- CREDIT --------------------------------------------------------------

This vulnerability was discovered by:

    Dino A. Dai Zovi
-------END---------------


It turns out that this affects Firefox on Mac OSX and Windows.  I'm not clear on how to represent that in the OS and Hardware fields for the bug, so I changed it to all.  Feel free to change it to something else if that's more appropriate.
OS: Mac OS X → All
Hardware: Macintosh → All
The write-up in comment #11 is _very_ obscure.  I don't know if
TippingPoint was testing us, or what.

The initial problem, from which everything else derives, is an integer
overflow -- 0x7FFFFFFF + 0x7FFFFFFF == 0xFFFFFFFE (i.e. -2).

The source code for quicktime.util.QTHandleRef.toQTPointer(int, int)
is misquoted.  Dino, like I, had to get the source by decompiling
QTHandle.class (from quicktime/util in QTJava.zip (stored in /System/
Library/Java/Extensions/)).  He (correctly) translated the parameters
from "int i" and "int j" (bestowed by the decompiler) to "int offset"
and "int size", but neglected to translate them in the body of the
method.

Fully translated, it reads as follows:

  public QTPointerRef toQTPointer (int offset, int size) {
    size = size + offset <= getSize() ? size : getSize() - offset;
    lock();
    return new QTPointerRef(lockAndDeref(offset), size, this);
  }

QTHandleRef.getSize() returns the size (in bytes) of the underlying
QTHandle object.  So it's not (quite) true that this method doesn't do
any sanity checking.  It just doesn't do it correctly -- the rather
wobbly sanity check will allow you to specify 0x7FFFFFFF for both
"offset" and "size", since they add up to '-2', which is less than
whatever the actual size of the QTHandle object might be.

That's enough for today.  Tomorrow I'll write an applet that crashes
Apple's QTJava and post it here (I won't bother trying for an
exploit).  Then I'll try to find out if there's any way I can use the
JEP to patch this hole.
OS: All → Mac OS X
Hardware: All → Macintosh
Oops.  Didn't mean to change the OS and Hardware fields.
OS: Mac OS X → All
Hardware: Macintosh → All
Here's the source code of the Java applet that I promised in comment
#13 -- one that crashes reliably in Firefox and Safari on OS X 10.4.9
and 10.3.9, and in Firefox on Windows XP.  It triggers the crashes by
writing one byte to absolute address 0xF0000000.

In my next message I'll post a zipfile containing the applet in a jar
file, the html code to invoke it, and (once more) the source code.
By the way, QTJava has _many_ other examples of pointer arithmetic
done in Java code (which inevitably uses signed integers).  I took a
quick (about one hour) stroll through the (decompiled) source code,
and didn't turn up any other potentially exploitable integer overflows
... but it'd be a _lot_ of work to give this code a through review.

It'll be up to Apple to decide how far they want to go in this
direction.

My "stroll"'s path was determined by doing a grep on getSize() :-)

Is there an easy way to block the vector in Firefox while we wait for them to fix the root cause?
I still don't know.  Or rather I don't know if there's a reasonably
"surgical" way to do it.  I could in principle replace the entire
quicktime.util.QTHandleRef.java file (the one that contains the
offending code) -- I'd include a copy in the JEP and make sure it was
loaded first (before the one in QTJava.zip).  But that'd be a lot of
work (in particular it'd require a lot of testing), and the result
would be quite fragile -- things would break if Apple subsequently
changed the "original".

A potentially more surgical approach involves leaving the offending
code alone, but trying to prevent it from doing damage by "hooking"
one or more native methods.  I'll spend a couple of hours looking into
this.

But considering that 1) Apple would be hard put to come up with a way
to patch this only for WebKit clients, 2) there could easily be other
integer overflows that no-one has yet found (but which people will now
be looking for) and 3) there probably isn't anything we can do for
Windows, this probably isn't worth spending a lot more time on.

> A potentially more surgical approach involves leaving the offending
> code alone, but trying to prevent it from doing damage by "hooking"
> one or more native methods.  I'll spend a couple of hours looking
> into this.

This didn't pan out.  So I haven't been able to find a reasonable way
to address this issue (on the Mac) at the level of the Java plugin.

I'm also pretty sure there isn't any way (on either the Mac or
Windows) to address this problem in the browser.

Even selectively disabling QTJava (by removing QTJava.zip from the
Java classpath) is only possible at the level of the Java plugin, on
the Mac.  And this would be pretty clumsy, since there (currently)
isn't any user-level setting to turn QTJava on or off.

I think our best bet (currently) is to wait for Apple to fix this
problem.

(In reply to comment #20)
> I think our best bet (currently) is to wait for Apple to fix this
> problem.

Unfortunately Apple has been pretty unresponsive to TippingPoint.  TippingPoint also just notified me that there is evidence of an exploit in the wild. It may have happened as a leak or perhaps someone captured it at CanSec.  We should consider this live.

I will try to get Apple to let us know what their ETA is, but we should keep working on this.  Could we constrain the input so that the IO can't be triggered?
Got ahold of Wiley Hodges (Senior Product Line Manager for Developer Products)at Apple.  He is running down a date for me,  but it looks like they are about a week out.  If this is the case, then this is likely the best solution for everyone.
> it looks like they are about a week out.  If this is the case, then
> this is likely the best solution for everyone.

Sounds good to me.

> Could we constrain the input so that the IO can't be triggered?

What do you mean?

(Of course, the _really_ dangerous IO (memory reading or writing) is
to or from "legal" addresses (which doesn't trigger a crash) --
e.g. overwriting the return address of the current function on a
(browser owned) stack.)

Reports of an exploit in the wild are starting to sound like FUD.  Apple is about a week out on a patch.  I think at this point we can relax unless we hear otherwise from Apple or TippingPoint.
Apple has just released their fix for this:

http://www.securityfocus.com/archive/1/467319/30/0/threaded
http://docs.info.apple.com/article.html?artnum=305446

Their fix appears to work in both Safari and Mozilla.org browsers on Mac OS X
10.4.9 and 10.3.9, and in Mozilla.org browsers and IE on Windows XP.  (I only
tested Firefox 2.0.0.3, but I assume I'd get the same results with the other
Mozilla.org browsers.  I tested with my QTPointerHole applet.)

I did notice one serious problem -- on OS X 10.3.9 the update from Software
Update didn't patch the hole in either Firefox or Safari (it didn't replace
QTJava.zip).  So I had to download QuickTime716.dmg and install from that.
I'm not sure why this happened (the Software Update QuickTime 7.1.6 update got
installed with one other update on 10.3.9, but by itself on 10.4.9, which may
have had something to do with it).  Somebody should probably tell Apple about
this.

For what it's worth, Apple seems to have missed some issues with its
first patch -- they've just release another version of QuickTime
(7.1.6) that patches QTJava problems:

http://www.infoworld.com/article/07/05/29/Apple-fixes-serious-QuickTime-bug_1.html
http://docs.info.apple.com/article.html?artnum=305531

Closing now that Apple fixed this in QuickTime. Any reason not to unhide the bug?
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
Whiteboard: [sg:nse] QuickTime bug, Apple released fix
Not that I can think of.
Group: core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.