This is my first site using the private file system, but as far as I can tell, the only thing that happens when you switch from public to private is that:
- your urls change
- hook_file_download() gets fired when a file is requested. So now you can implement this hook in your code (or get a module that does) and decide whether to serve the file or not.
The Imagecached images get sent to imagecache_cache_private(), which checks to make sure the user has access to the preset before serving the image. But it doesn't check anything else. I believe this means that you could request any image on the site if you knew the name of the preset and the name of the image because Imagecache doesn't check for file download permissions. To demonstrate:
example.com/files/image.png
is denied by hook_file_download, but
example.com/files/imagecache/extra_large/image.png
will be displayed if you have access to the preset 'extra_large'.
in imagecache_cache_private() I think there should be a call to module_invoke_all('file_download', $source, $preset)
to ensure that the user has access to the original file as well as the preset. The attached patch adds that check.
Comment | File | Size | Author |
---|---|---|---|
#4 | imagecache_505904.D6.patch | 803 bytes | drewish |
#4 | imagecache_505904.D5.patch | 742 bytes | drewish |
#2 | 505904_imagecache_file_download.patch | 642 bytes | kscheirer |
imagecache_file_download.patch | 613 bytes | kscheirer |
Comments
Comment #1
csevb10 CreditAttribution: csevb10 commentedFirst, this patch makes complete sense, and I would definitely consider it a security/privacy hole. I think the approach is correct to solving the issue, I think just a small tweak is required for it to be in working order.
The module_invoke_all call will return an array. The default call to module_invoke_all for file_download uses the following check: if (in_array(-1, $headers)). It seems like it'd make sense to do the same thing here.
Comment #2
kscheirergood point, attached a new patch.
Comment #3
csevb10 CreditAttribution: csevb10 commentedLooks good to me now.
Comment #4
drewish CreditAttribution: drewish commentedhere are patches that actually apply. i think we might need to revisit this later because we're discarding the headers returned by hook_file_download(). but for now it's an improvement.
Comment #5
drewish CreditAttribution: drewish commentedcommitted to HEAD.
Comment #6
kscheirerthanks drewish, rolled patched from the wrong document root by mistake.
Comment #7
drewish CreditAttribution: drewish commentedoh the problem was that that the first patch had to be applied and then the second, rather than just applying one patch. also for future refererence you should report security issues to the security team. it helps insure that issues like this don't languish unnoticed.
Comment #9
rose2 CreditAttribution: rose2 commentedI do agree that you should attach a new patch for it, if the first one doesn't work. You may also search it for further clarification and information. thanks for the post. [scottsdale security systems]