purple_util_fetch_url vulnerability

[Daniel Atallah]

This comes from "Jacob Appelbaum of the Tor Project" who contacted me privately.

I assume we don't want to try to delay 2.10.7 to address this, but it
probably means that we'll be releasing again soon :(

It looks like this is mostly addressed in the http rewrite that Tomasz
Wasilczyk did in default (I didn't look super closely at it, but I did
notice that it doesn't seem to suffer from the unbounded heap
allocation going on here).

Here's the information:

Jacob Appelbaum: basically, purple_util_fetch_url_request is totally unsafe
Jacob Appelbaum: well, note how it looks at the http length? :)
Jacob Appelbaum: i'll find the exact line
Jacob Appelbaum: libpurple/util.c:purple_util_fetch_url_request
Jacob Appelbaum: parse_content_len() is well, unsafe also
Jacob Appelbaum: the money shot is in url_fetch_recv_cb()
Daniel Atallah: Sorry, I have to run.
Jacob Appelbaum: so that is the remote heap/stack overflow
Daniel Atallah: Can we talk about his later?
Jacob Appelbaum: leave pidgin open and i'll dump the bug to you
Jacob Appelbaum: specifics, i mean
Daniel Atallah: ok
Jacob Appelbaum: basically:
Jacob Appelbaum: 4303 if (content_len == 0) {
Jacob Appelbaum: 4304 /* We'll stick with an initial 8192 */
Jacob Appelbaum: 4305 content_len = 8192;
Jacob Appelbaum: 4306 } else {
Jacob Appelbaum: 4307 gfud->has_explicit_data_len = TRUE;
Jacob Appelbaum: 4308 }
Jacob Appelbaum: 4309
Jacob Appelbaum: int overflow, I think:
Jacob Appelbaum: 4313 gfud->data_len = content_len + header_len;
Jacob Appelbaum: then we realloc:
Jacob Appelbaum: 4314 gfud->webdata = g_realloc(gfud->webdata, gfud->data_len);
Jacob Appelbaum: then we pick the largest:
Jacob Appelbaum: 4317
Jacob Appelbaum: 4318 content_len = MAX(content_len, body_len);
Jacob Appelbaum: we then malloc without an upper bounds or a lower bounds check:
Jacob Appelbaum: 4320 new_data = g_try_malloc(content_len);
Jacob Appelbaum: then we memcpy:
Jacob Appelbaum: 4334 /* We may have read part of the body when
reading the headers, don't lose it */
Jacob Appelbaum: 4335 if (body_len > 0) {
Jacob Appelbaum: 4336 memcpy(new_data, end_of_headers + 4, body_len);
Jacob Appelbaum: so that basically means that every time you get
pidgin to fetch a url (including buddy icon references) - we can
trigger either ssl bugs (currently shipping) or a heap or stack
overflow in the http parser
Jacob Appelbaum: then there are png parsing issues but that is much later
Jacob Appelbaum: anyway, that bug is pretty bad news
Jacob Appelbaum: i have others but that is the one that should be
fixed right off
Jacob Appelbaum: i have to triage the other bugs
Jacob Appelbaum: the entire HTTP code base is pretty sketchy
Jacob Appelbaum: anyway, that is easily remotely exploitable, I think
- we just need an attacker controlled HTTP server to lie about content
length vs actual length, etc
Jacob Appelbaum: please credit it as Jacob Appelbaum  of the Tor Project