Remotely triggerable crash

Daniel Atallah datallah at
Mon Sep 13 14:22:12 EDT 2010

On Fri, Sep 10, 2010 at 14:30, Daniel Atallah <datallah at> 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, 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:
  * 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
 * 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.
 * An invalid base64 encoded login challenge is received.
 * 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.

-------------- 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: <>

More information about the security mailing list