RemoteUser-supplied local file paths
mark at kingant.net
Thu Jan 10 04:25:29 EST 2013
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:
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
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?
More information about the security