Safari HTTPS Overflow

[Gilbert Verdian]

Found a bug in the latest Safari that comes with Panther 10.3.9 -
Safari 1.3 (v312), previous versions of Panther are also vulnerable.

The problem is with the URI input for HTTPS which causes Safari to
crash by inputting a large amount of A's i.e.

https://
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Did a debug of the crash, but it kept crashing in a spin_lock while
reading from the text segment. Will post more details when have more
info on it.

Gilbert Verdian
neoresearch.org

[David Riley]

I don't think this is an overflow. According to gdb, the spin lock
from CFSocketEnableCallBacks is crashing. Backtracing to the call of
CFSocketEnableCallBacks, I see that the two parameters (a CFSocket
pointer and a set of binary flags, respectively) are:

r3 0x0 0
r4 0x9 9

Thus CFSocketEnableCallBacks is being passed a NULL pointer (and, for
what it's worth, the flags are kCFSocketReadCallBack and
kCFSocketWriteCallBack). Why it crashes in the spinlock, I'm not sure,
but I imagine it might have to do with gdb not behaving nicely with
threads.

In any case, since I don't see any registers getting overwritten with
either 0x41 or 0x61 (since Safari converts it to lowercase), I don't
really see an overflow. It's a crash which you might want to report to
Apple, but it seems like it's probably just a case of dereferencing a
NULL pointer.

I think what's happening is that some handler somewhere for the URL is
seeing an overly large buffer and rejects it with a NULL pointer
somewhere for the socket which isn't checked for appropriately.

Thanks,
David

[Braden Thomas]

Gilbert =96
This appears to be an issue where Safari is calling =20
CFSocketEnableCallBacks on a null CFSocketRef. Not an overflow. An =20
overflow would require a buffer, somewhere, to have overflowed. This =20=

is not happening at all. Just because a program crashes when you send =20=

it a relatively long string does not define it as an overflow. Look at =20=

the crash report:

Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x0000000c

Also, did you notify Apple =20
(https://bugreport.apple.com/cgi-bin/WebObjects/RadarWeb.woa) of this =20=

bug, or did you just figure they'd hear about it through the grapevine?

Braden Thomas

On Apr 28, 2005, at 2:08 PM, Gilbert Verdian wrote:

> Found a bug in the latest Safari that comes with Panther 10.3.9 - =20
> Safari 1.3 (v312), previous versions of Panther are also vulnerable.
>
> The problem is with the URI input for HTTPS which causes Safari to =20
> crash by inputting a large amount of A's i.e.
>
> https://=20
> =
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAA=20=

> =
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAA=20=

> =
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAA=20=

> =
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAA=20=

> =
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAA=20=

> =
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAA=20=

> =
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAA=20=

> =
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAA=20=

> =
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAA=20=

> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
>
> Did a debug of the crash, but it kept crashing in a spin_lock while =20=

> reading from the text segment. Will post more details when have more =20=

> info on it.
>
> Gilbert Verdian
> neoresearch.org