Re: Safari HTTPS Overflow

From: David Riley (oscar_at_the-rileys.net)
Date: 04/29/05

  • Next message: Braden Thomas: "Re: Safari HTTPS Overflow" 
    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

  • Next message: Braden Thomas: "Re: Safari HTTPS Overflow"