[pidgin-security] possible segfault in perl wrapper

Elliott Sales de Andrade qulogic at pidgin.im
Thu Apr 11 22:15:23 EDT 2013

On 11 April 2013 21:30, Tomasz Wasilczyk <tomasz at wasilczyk.pl> wrote:
> Hi,
> please read this short discussion and give me opinion, what should I
> do. Should I treat this as security fix and postpone committing until
> just before release?

I'm not sure this really qualifies as a security problem. For one, it
only affects Perl code. Second, it needs to be triggered somehow. But
it can't, in Pidgin or Finch or libpurple, since none of our Perl code
actually calls purple_network_ip_atoi.

Also, I'm a bit unclear about the attack vector here. I tried to write
a Perl plugin that used the function, but it didn't crash simply by
calling it (as it seems to be implied here). I also see no related
errors in valgrind. Maybe it would crash if you used the result as a
string but not as an array of 4 bytes like the documentation says you
should? I don't really know enough Perl to test that difference,

> Tomek
> ---------- Forwarded message ----------
> From: Ben Laurie <benl at google.com>
> Date: 2013/4/11
> Subject: Re: [pidgin-security] possible segfault in perl wrapper
> To: Tomasz Wasilczyk <tomasz at wasilczyk.pl>
> On 10 April 2013 18:57, Tomasz Wasilczyk <tomasz at wasilczyk.pl> wrote:
>> Hi,
>> I have found a theoretically possible segfault in perl wrapper.
>> Libpurple wraps purple_network_ip_atoi [1] with [2]. The first one
>> returns 4-byte buffer, but the second one returns C-string (because of
>> [3] mapping). Result: 4-byte raw buffer is copied as C-string using
>> strlen.
>> I hardly believe, that anyone is affected, because this function
>> doesn't seems to have ever been working.
>> Also: do you think, that such bug should be treated as "sensitive", or
>> can be safely assumed that no one actually uses that feature.
> Sounds to me that it might have been used, in fact, since 0s in real
> IP addresses are relatively rare (there was a time when lots of things
> broke if you had a 0 anywhere), so the string copy will _usually_
> yield the right value (plus a buffer overflow!). So, I suspect it
> should be considered somewhat sensitive.
>> Proposed solution:
>> remove it from Pidgin 3.0.0 and disable in 2.x.y.
>> [1] https://hg.pidgin.im/pidgin/main/file/90201925e1fe/libpurple/network.c#l125
>> [2] https://hg.pidgin.im/pidgin/main/file/90201925e1fe/libpurple/plugins/perl/common/Network.xs#l22
>> [3] https://hg.pidgin.im/pidgin/main/file/90201925e1fe/libpurple/plugins/perl/common/typemap#l33

Elliott aka QuLogic
Pidgin developer

More information about the security mailing list