potential security vulnerabilities

[Benjamin Bowman]

Eion,

Thanks for getting back to me!  I do not have any proof-of-concept
crashes.  The techniques i'm researching at this point are purely static
analysis and do not involve any runtime.

Basically what I'm going off of here is that these functions parse strings
from untrusted network data (I think), in a way similar to receiveauthgrant
and receiveauthreply (in family_feedbag.c).  Those two functions, as well
as many others throughout the codebase, validate that the string input is
indeed UTF-8 (e.g. keyparse in family_auth.c, parseicon in family_bart.c).
So, when I saw these two functions reading strings and not validating, I
thought it may be a potential vulnerability.

The glaring assumption here is that these functions are parsing untrusted
data.  If, as I think you touched on in your last email, these functions
are not dealing with any user taintable data, then these are likely not a
problem.  If this is indeed the case, then I will mark these as false
positives and work on refining my methods.

Thanks,
Ben

On Mon, Jun 18, 2018 at 12:48 AM, Eion Robb <eion at robbmob.com> wrote:

> 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/857d9308/attachment-0001.html>