MXit PRPL user-supplied file paths

[Andrew Victor]

hi Mark,

1. libpurple/protocols/mxit/splashscreen.c:

The value is received over the network from the MXit server only, and it is not possible for a client to send this packet to another user.
I don't foresee any method to exploit this remotely.


2. libpurple/protocols/mxit/formcmds.c

These messages can be sent from one client to another (assuming the recipient has accepted the sender as a contact).

The sender would need to modify Pidgin source to send a specially crafted message, and force the messageType field to CP_MSGTYPE_COMMAND.

   g_strdup_printf("%s/%s-%s-%s.png", dir, from, name, validator);

The "from" is the internal MXit userId of the message sender, and cannot be controlled by sender (ie, no escaping required).
The "name" and "validator" can be controlled by the sender and should be escaped.

Since the filename format above always ends in ".png", does that not mean that only PNG files can be created or overwritten?
The string is not URL-decoded, so if an %00 is inserted it's still not possible to terminate the string before the extension.
(ie, no ../../../../passwd possible)

Regards,
 Andrew Victor



________________________________________
From: Mark Doliner [mark at kingant.net]
Sent: 06 January 2013 10:05 PM
To: Andrew Victor; Pidgin Security
Cc: Chris Wysopal
Subject: MXit PRPL user-supplied file paths

Chris Wysopal and Veracode found places in our code where we write a
file to the local disk using a filename that partially comes from the
network.  This is dangerous because the filename could potentially
contain something like "../../.bashrc" or "../../../../../etc/passwd"
and we could overwrite something that the user cares about.

This email concerns the two places where the MXit code does this.
Please see the attached patch against the 2.x.y branch.  Am I correct
that some parts of the filename come in from the network?  Do my
changes look like they'll fix the problems?

Next question: Is it possible for a remote user to specify the values
for these variables?  If so, I think we should obtain a CVE for this
and go through the embargoed disclosure process.  But if the values
are specified by the MXit server and not by a remote user then I think
it's fine to commit this to 2.x.y and release at our leisure.