RemoteUser-supplied local file paths

Eion Robb eionrobb at
Thu Jan 10 13:36:30 EST 2013

I think #3 is best as it provides maximum protection from dummy 3rd party
plugins that may not escape anything

On Jan 10, 2013 10:25 PM, "Mark Doliner" <mark at> wrote:

> This is email 2 of 2 concerning a probable CVE-worthy issue bought up
> by Chris Wysopal and Veracode.  (As a reminder, email 1 of 2 concerned
> MXit code and we've agreed that we'll obtain a CVE for those issues.)
> In 2.x.y these files call purple_imgstore_add_with_id() and set the
> filename to an unescaped value read from the network:
> - libpurple/protocols/gg/gg.c:1402
> - libpurple/protocols/oscar/odc.c:359
> - libpurple/protocols/sametime/sametime.c:2785
> The file is then written to disk in purple_buddy_icon_data_cache()
> using the unescaped filename.  I'd love if someone could look at these
> few bits of code and confirm that this problem is real and I'm not
> wrong.
> Possible fixes:
> 1. Update those three prpls to escape the filename using
> purple_escape_filename() before calling purple_imgstore_add_with_id().
> 2. Update purple_imgstore_add_with_id() to escape the filename in the img.
> 3. Update purple_buddy_icon_data_cache() to escape the filename before
> writing to disk.
> Option #1 is the easiest and least intrusive, but leaves open the
> possibility that I've missed a few places, and leaves open the
> possibility of this problem recurring in the future.  Option #2 is a
> little scary because I think we might use the "filename" field for
> more than just the filename.  Maybe we use it as a hash table key?  Or
> show it to the user as a friendly name for an image?  I don't know.
> Anyone have an opinion?
> _______________________________________________
> security mailing list
> security at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the security mailing list