[pidgin-security] possible segfault in perl wrapper

[Tomasz Wasilczyk]

2013/4/12 Elliott Sales de Andrade <qulogic at pidgin.im>:
> 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.

It really affects only 3rd party plugins that uses
purple_network_ip_atoi (are there any?).

> 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,
> though.

As Perl documentation says, buffer size is estimated using strlen.

Thus, I see here two different cases:
1. ip address contains zero (127.0.0.1), resulting buffer will have
length shorter than 4 bytes
2. there will be no "safe-to-read" zeros in memory after ip address
buffer, segfault should occur

But these two are just theoretical considerations.

>
>> 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