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