Possible null pointer dereference in msn httpconn.c

[Mark Doliner]

The below patch is simple enough to fix the crash in question.

There's kind of a bigger question as to what the best behavior is in this
situation.  If SessionID token is missing because the user is being
man-in-the-middle attacked then we probably want to throw away the entire
packet because it could have been tampered with.  But then if someone is
tampering with your MSN session they could just as easily include a usable
SessionID.  So you don't gain much from throwing away the packet.

We could assume the packet is legitimate and just not something we know how
to parse, and we could try to continue with our session.  If this is
something we care about then msn_httpconn_parse_data() probably shouldn't
call msn_httpconn_process_queue() until we actually have a session id.  But
the HTTP method isn't even the default connection method, so I don't know
how much we care about this.

--Mark

============================================================
--- libpurple/protocols/msn/httpconn.c
f3ca08ffa5671a256777e2791c1c2bd7307744cb
+++ libpurple/protocols/msn/httpconn.c
6bfb5c975be23a647a5f61f0e15174adddb30ea6
@@ -217,7 +217,7 @@ msn_httpconn_parse_data(MsnHttpConn *htt

g_free(tmp);

- t = strchr(full_session_id, '.');
+ t = full_session_id ? strchr(full_session_id, '.') : NULL;
if (t != NULL)
session_id = g_strndup(full_session_id, t - full_session_id);
else {
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/cgi-bin/mailman/private/security/attachments/20110508/c8554671/attachment.html>