[pidgin-security] possible segfault in perl wrapper

[Tomasz Wasilczyk]

I've written simple test for it (see attachment) and it turned out, that:

- result buffers shorter than 4 bytes doesn't hurt perl, the only
issue is that some IP addresses are malformed (192.168.0.1 ->
192.168.0.0).
- when using addresses without zeros, resulting buffer length is 4
bytes, so there is no buffer overflow (there should be 1 byte for
'\0', but valgrind doesn't show anything). But I'm not sure, why there
is a zero after source buffer, that makes it working.

Anyway, I see no real possibility to exploit this. I propose simply
patching it without "security" tag (that means now, without waiting
for just-before-release) for 2.x.y by replacing sv_setpv with
sv_setpvn and removing it entirely from 3.0.0.

Tomek

2013/4/12 Tomasz Wasilczyk <tomasz at wasilczyk.pl>:
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: atoi-test.pl
Type: application/octet-stream
Size: 1055 bytes
Desc: not available
URL: <http://pidgin.im/cgi-bin/mailman/private/security/attachments/20130414/dd0ab262/attachment.obj>