RemoteUser-supplied local file paths

[Eion Robb]

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

Cheers,
Eion
On Jan 10, 2013 10:25 PM, "Mark Doliner" <mark at kingant.net> 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 pidgin.im
> http://pidgin.im/cgi-bin/mailman/listinfo/security
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/cgi-bin/mailman/private/security/attachments/20130111/fc8a44e0/attachment.html>