Remotely triggerable crash
Daniel Atallah
datallah at pidgin.im
Mon Sep 13 14:22:12 EDT 2010
On Fri, Sep 10, 2010 at 14:30, Daniel Atallah <datallah at pidgin.im> wrote:
> NOTE: This is non-public information, please don't post it publicly
> (including committing fixes to public repositories) until after a
> coordinated public disclosure has been made (e.g. after the release
> containing the fix).
>
> While investigating http://developer.pidgin.im/ticket/12614, I've
> discovered what appears to be a remotely triggerable crash in the
> yahoo protocol.
>
> If we receive a particular status key value that is NULL or has a
> length of 1, a NULL pointer will be dereferenced.
>
> The problem is that the return value of purple_base64_decode() isn't
> being examined to make sure it isn't NULL before looking at the
> changed-by-reference "length" value (which will not be set if the
> function has failed to complete successfully). The mistaken
> assumption is that if the "length" parameter ends up being >0, then
> the function has succeeded.
>
> As you can see in the ticket referenced above, this is something that
> is already happening.
>
> I looked through other uses of purple_base64_decode() and
> purple_base16_decode() (which works in a similar way) and there appear
> to be a number of other places where additional validation will need
> to be done. It is possible that some of these are also exploitable,
> but I need to look more carefully to be sure.
>
> I'll come up with a patch in the next few days and we can figure out a
> plan for a coordinated release, but I figured I'd give everyone a
> heads up and get a few more eyes to evaluate the impact.
I have attached the patch that should fix the places where the API is
being misused in the way described above.
Based on the fixes in the patch, I believe that the following remotely
triggerable NULL pointer dereferences exist:
Yahoo:
* An invalid base64 yahoo value related to a buddy icon transfer is
received and an uninitialized variable (passed by reference for
length) has a non-zero value
* An invalid base64 yahoo value intended to contain the IP address
for a P2P connection is received and an uninitialized variable (passed
by reference for length) has a non-zero value
MSN:
* An invalid base64 file transfer header is received and an
uninitialized variable (passed by reference for length) has a value >
the size of a struct.
NTLM: (used for proxy authentication and SIP/SIMPLE authentication)
* An invalid base64 "Type 2" message is received.
MySpace:
* An invalid base64 encoded login challenge is received.
XMPP:
* An invalid base64 encoded Digest-MD5 authentication challenge is
received (only applies when Cyrus SASL is either unavailable or
doesn't provide Digest-MD5 support).
I'd appreciate it if someone could review the above evaluation and
make sure that I'm not misunderstanding what could happen.
Thanks,
-D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: baseXX_decode_error_handling.patch
Type: application/octet-stream
Size: 6999 bytes
Desc: not available
URL: <http://pidgin.im/cgi-bin/mailman/private/security/attachments/20100913/00474c8f/attachment.obj>
More information about the security
mailing list