bugtraq - Re: Safari HTTPS Overflow

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 28 Apr 2005 22:19:26 -0400
From: David Riley <oscar@...-rileys.net>
To: Gilbert Verdian <gverdian@...research.org>
Cc: bugtraq@...urityfocus.com, vuln-dev@...urityfocus.com
Subject: Re: Safari HTTPS Overflow

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