libpurple gadu-gadu issues

[Lukas Odzioba]

2013/8/20 Tomasz Wasilczyk <tomkiewi at gmail.com>:
> I'm not sure, if we should deal with the cases, where the attacker is
> able to spoof the server.

I think you should, and you already did it for other protocols:
http://www.pidgin.im/news/security/?id=66
http://www.pidgin.im/news/security/?id=67
http://www.pidgin.im/news/security/?id=40

> If user enables encrypted connections, he's
> safe, if he disables it, he's as vulnerable, as in any other protocol
> (the xmpp roster is also able to add/remove buddies remotely).

BTW I checked handy slackware and ubuntu packages, on both systems
encryption is not enabled by default and setting "Use encryption if
available" does not change anything in my case.
Besides encryption does not prevent you from connecting to wrong server.
And I still don't like the idea that someone/someserver can add
friends to my list against my will, especially if this can be avoided.

> However, I've removed buddy list uploading/downloading feature,
> because it doesn't work as expected for now (it's a problem on the
> Gadu-Gadu service provider side).

I just tested downloading from an official server and it works fine
(list in "GG70ExportString" format).

> I have similar reflection as before: you can force memory allocation
> on any protocol, just by sending millions of messages. When you act as
> a server, you don't need to obey any anti-spam limits.

This does not change the fact that allowing arbitrarily long buddy
lists is a bug, isn't it?
When you spam user with messages he will probably notice that, when
you spam him with such crafted packets he probably won't notice the
reason (pidgin does not respond, cpu usage is close to 100%, memory
footprint grows up to ridiculous values (1GB = 16384 packets).
Also this memory is not freed up after end of such attack, or there is
a memleak when realloc fails.

> Fixed and sent as a pull request for the upstream.

Thanks,
Lukas