libpurple gadu-gadu issues

[Tomasz Wasilczyk]

2013/8/18 Lukas Odzioba <lukas.odzioba at gmail.com>:
> 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.

I'm not sure, if we should deal with the cases, where the attacker is
able to spoof the server. 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).
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).

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

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.

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

Fixed and sent as a pull request for the upstream.

> Lukas
> _______________________________________________
> security mailing list
> security at pidgin.im
> http://pidgin.im/cgi-bin/mailman/listinfo/security