potential security vulnerabilities

[Eion Robb]

Hi Benjamin,

Thanks for taking the time to send through these potential vulnerabilities.

Do you have a proof-of-concept crash for either of these string parsing
issues, or are they just theoretical at this stage?

I'm not an expert on the Oscar code by any means (and hopefully someone
else jumps in to correct me!), but my reading of the 2011 CVE was that it
was a problem because it could be exploited by a remote user, whereas the
two examples you've provided are for data that only comes from
server-side?  Do you have any examples of how they might be used against a
Pidgin user?

Cheers,
Eion


On Tue, 12 Jun 2018 at 02:09, Benjamin Bowman <bbowman410 at gwmail.gwu.edu>
wrote:

> 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'.
>
> _______________________________________________
> security mailing list
> security at pidgin.im
> https://pidgin.im/cgi-bin/mailman/listinfo/security
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pidgin.im/cgi-bin/mailman/private/security/attachments/20180618/32f336a0/attachment.html>