Gadu-Gadu security issues

Tomasz Wasilczyk tomkiewi at gmail.com
Mon Jan 28 09:23:57 EST 2013


2013/1/28 Mark Doliner <mark at kingant.net>:
> These problems either aren't remotely-exploitable or don't affect
> Pidgin users, right?

Exactly.

> Tomasz, your patch looks good to me.  If there
> are no objections, I propose:
> - Tomasz, please commit your patch to the release-2.x.y branch at your
> earliest convenience.
> - Then Tomasz merges the changes from this branch into main using "hg
> merge release-2.x.y" from within main and resolves conflicts.
> - Tomasz passes this information (and I guess your patch? totally up
> to you) along to the upstream libgadu project.

ok

> The one bug I'm most unsure about is the realloc() buffer overflow
> thing (CID 732073, libpurple/protocols/gg/lib/common.c:117).
>
> That code is ugly and seems kinda wrong to me.  For example, why call
> vsnprintf() twice?  And the loop condition to decide whether to
> reallocate seems wrong--the vsnprintf() man page says, "If the output
> was truncated due to this limit then the return value is the number of
> characters (excluding the terminating null byte) which would have been
> written to the final string if enough space had been available."  But
> the code looks like it's expecting to receive either -1 or size-1.

This code was rewritten in upstream trunk [1].

The loop condition was written for non-standard-compliant systems -
some of them doesn't calculate resulting string length.

> I kinda feel like that code will overflow buf by exactly 1 byte every
> time the string is >128 bytes.  But it seems like this hasn't been a
> source of crashes, so I'd say we should patch it in 2.x.y but not
> consider a remotely-exploitable crash.

I think just the same way.

[1] http://toxygen.net/websvn/filedetails.php?repname=libgadu&path=%2Ftrunk%2Fsrc%2Fcommon.c


More information about the security mailing list