libpurple gadu-gadu issues

Tomasz Wasilczyk tomkiewi at gmail.com
Sat Sep 6 06:50:40 EDT 2014


2014-09-05 22:47 GMT+02:00 Lukas Odzioba <lukas.odzioba at gmail.com>:

> 2013-08-28 23:08 GMT+02:00 Ethan Blanton <elb at pidgin.im>:
> > I mean we should deal with a fake server safely, as well.  I'm not
> > sure I get the point you're making.
>
> It's been a while, I assume it is fixed by now. Shouldn't you/I/we
> request a cve for that?
>

We've been talking about three issues:
1. a possibility to use a feature, that doesn't officially exists in the
(old version of) protocol
2. a possibility for the attacker to allocate a memory on the client
3. a buffer overflow

The third one is fixed. The second one is a common "issue" for any IM
protocol (because we may allocate any amount of memory by just sending text
messages).


I think the majority of our discussion was about the first cause. Let's
define an attack: it's the possibility (for the server) to alter the buddy
list.

As you stated, it should not be possible with the old protocol and the
original client. We could take steps to defend against this type of fraud.
But my point is, the new protocol and other protocols (like xmpp) provides
legitimate features like this (buddy list synchronization) and the
"attacker" could use these to perform an attack. In such case, it won't be
possible to determine, if it's an attack or a normal server request.

Please note, that this is a situation, where the attacker already gains a
control over a server-client transmission. And again, in my opinion there
is no point to protect against issues caused by invalid packets, while the
attacker might use legitimate packets to gain the same goal.


Summarizing up, I think the only one CVE worth requesting is only the third
issue mentioned before. But my opinion might not be the same as other devs.
Elb? Please correct me if I'm wrong.

Thanks,
Tomek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pidgin.im/cgi-bin/mailman/private/security/attachments/20140906/b359379a/attachment.html>


More information about the security mailing list