libpurple gadu-gadu issues

[Lukas Odzioba]

Hi,
I found some interesting stuff in gadu-gadu protocol implementation,
all three in function:
handlers.c:
static int gg_session_handle_userlist_reply(struct gg_session *gs,
uint32_t type, const char *ptr, size_t len, struct gg_event *ge)

First two looks serious, and both can be exploited by remote server or
an attacker able to intercept tcp traffic.

1)
By sending GG_USERLIST_REPLY packet an attacker is able to add
"friends" to users buddylist :)
After this action user will be notified by MessageBox that buddy list
was downloaded from server, but will have no idea what changed.
Yes, this might be considered as a "feature", but for me it is invalid
protocol implementation and security problem which might lead to
frauds.

Suggeseted fix:
Ignore GG_USERLIST_REPLY/GG_USERLIST_GET_REPLY packets unless user
decided to download the list from server + time window in which we
accept such packets after user action.

2)
Since there is no limit on buddylist size attacker can force app to
allocate as much memory as he wants by sending
GG_USERLIST_REPLY/GG_USERLIST_GETMORE_REPLY packets. This memory won't
be freed until app will get GG_USERLIST_GET_REPLY packet.

tmp = realloc(gs->userlist_reply, reply_len + len);

In practice I was able to hang my 1GB laptop remotelly using this attack.

Suggested fix:
Add length limit for buddylist. Cleanup after timeout if we don't get
next chunks in time.

A)
reply_type = ptr[0];

This read assumes that count > 0 but min packet size (size_t len) is
defined as 0 here:
{ GG_USERLIST_REPLY, GG_STATE_CONNECTED, 0, gg_session_handle_userlist_reply },

It is just one byte, and I think it does not produce overflow, but
still it might be worth fixing anyway.

Lukas