[38678] in bugtraq
Re: Safari HTTPS Overflow
daemon@ATHENA.MIT.EDU (David Riley)
Fri Apr 29 12:45:03 2005
In-Reply-To: <5857F6B3-C1DF-4694-BE0B-5D85F0BE4133@neoresearch.org>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <6e23d876aab050f1ef6059d2d6342bc3@the-rileys.net>
Content-Transfer-Encoding: 7bit
Cc: bugtraq@securityfocus.com, vuln-dev@securityfocus.com
From: David Riley <oscar@the-rileys.net>
Date: Thu, 28 Apr 2005 22:19:26 -0400
To: Gilbert Verdian <gverdian@neoresearch.org>
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
