potential security vulnerabilities

[Benjamin Bowman]

Hello,

My name is Benjamin Bowman and I am a PhD student currently doing security
research at the George Washington University.  I have been working on
methods for identifying new vulnerabilities in source code using existing
CVE data.

I have found two functions in the libpurple oscar protocol that I believe
may be vulnerable in a similar manner to an existing CVE.  The reference
vulnerability is CVE-2011-4601.  The vulnerability allowed remote crashes
because of missing validation on certain fields.  Specifically, strings
were not being verified as UTF-8 encoded before they were passed on to
other functions which treat them as such.

I have outlined the potential vulnerabilities below.  Please let me know if
these are indeed vulnerabilities as it will help in my research.

Thanks!
Benjamin Bowman
George Washington University

=============The first potential vulnerability:

*File*:
libpurple/protocols/oscar/family_icbm.c

*Function*:
static int clientautoresp(OscarData *od, FlapConnection *conn, aim_module_t
*mod, FlapFrame *frame, aim_modsnac_t *snac, ByteStream *bs)

*Reason*:
This function parses the 'bn' variable directly from the ByteStream 'bs':

bn = byte_stream_getstr(bs, bnlen)

This variable is passed directly to the callback function 'userfunc'
without any validation on the encoding:

ret = userfunc(od, conn, frame, channel, bn, reason);

This is the same scenario as in CVE-2011-4601, and the fix was to verify
the variable was UTF-8 encoded prior to passing it on to 'userfunc'.

=============The second potential vulnerability:

*File*:
libpurple/protocols/oscar/family_admin.c

*Function*:
static void infochange(OscarData *od, FlapConnection *conn, aim_module_t
*mod, FlapFrame *frame, aim_modsnac_t *snac, ByteStream *bs)

*Reason*:
Similar to the previous scenario, there are three instances where strings
are parsed directly from ByteStream 'bs':

sn = byte_stream_getstr(bs, length);
url = byte_stream_getstr(bs, length);
email = byte_stream_getstr(bs, length);

These variables then have the ability to be passed directly to the callback
function 'userfunc' without any validation on the encoding:

userfunc(od, conn, frame, (snac->subtype == 0x0005) ? 1 : 0, perms, err,
url, sn, email);

This is the same scenario as in CVE-2011-4601, and the fix was to verify
the variable was UTF-8 encoded prior to passing it on to 'userfunc'.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pidgin.im/cgi-bin/mailman/private/security/attachments/20180611/6b9991ec/attachment-0001.html>