RemoteUser-supplied local file paths
eionrobb at gmail.com
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 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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the security