MXit security flaws
Daniel Atallah
daniel.atallah at gmail.com
Mon Dec 17 14:54:51 EST 2012
In the interest of making progress toward getting a 2.10.7 out the
door and getting the known security issues resolved in it, here are
some issues that need analysis.
This comes from the Coverity static analysis.
Note that fixes for these shouldn't be pushed to the main repository
until we're about to release.
Unfortunately there doesn't appear to be a way to export the data from
the coverity website, but here's the info:
CID 732102: (This is the most critical one)
* String not null terminated. In mxit_cb_http_read: A character
buffer that has not been null terminated is passed to a function
expecting a null terminated string
* libpurple/protocols/mxit/http.c:133 -> ch = strstr( buf, HTTP_11_SEPERATOR );
"buf" may not be nul-terminated there because of how it's being read
on line 119.
When looking into it, it appeared to me that in addition to the lack
of null termination, "buf" can be easily overrun by sending it more
data than fits in it and having session->rx_dbuf grow bigger than
what'll fit in buf.
CID 732105:
* Copy into fixed size buffer. In mxit_encrypt_password: A source
buffer of statically unknown size is copied into a fixed-size
destination buffer
* libpurple/protocols/mxit/cipher.c:93 -> strcat( pass,
session->acc->password );
You might overrun the 64 byte fixed-size string "pass" by copying
"session->acc->password" without checking the length.
CID 732025:
* Explicit null dereferenced. In mxit_send_extprofile_update:
Dereference of an explicit null value
* libpurple/protocols/mxit/protocol.c:871 -> datalen += sprintf(
data + datalen, "%c%s%c%s%c%s", ...
I'm not sure this is really possible, but it's worth looking into.
Dereferencing null pointer "parts" (this happens when "attributes" is
null, but "nr_attrib" > 0)
More information about the security
mailing list