Gallery 1.4.4 save_photos.php PHP Insertion Proof of Concept By aCiDBiTS acidbitshotmail.com 17-August-2004 ++ Vulnerability description ++ Gallery (http://gallery.sf.net/) is a PHP image gallery script. Having permission to upload photos in some album and the temporal directory is in the webtree, then it is possible to create a file with any extension and content. Tested in v 1.4.4, maybe older versions also vulnerable. When uploading photos with the "URL method", they are saved in the temporal directory before processing them. Any file with any content is accepted. After downloading, the file is processed (discarded if it is not an image) and deleted from the temporal directory. When the script downloads the file to the temporal directory there's the function set_time_limit() that by default waits 30 seconds to abort the process if no more data is recieved and the transfer connection isn't closed. If the temporal directory is in the webtree, during this 30 seconds timeout we can access to the file, executing it. There's also a "directory disclosure" that I've used to determine if the temporal directory is in gallery's webtree. It consists in sending a longer filename than permited by the filesystem for the image upload name. ++ How this Proof of Concept works ++ 1. You need to have a fake image script (like galfakeimg.php) in a web accessible by gallery to download it. 2. The script searches for an Album with "everybody" permission to add photos. 3. Checks if the temporal directory is in the webtree. 4. Tell gallery to download the fake_photo that contains the script. 5. After XEC_TIMEOUT seconds waiting, it executes the temp file and test.php is created. Usage (in my debian box): php4 -q ./gal_poc.php "http://192.168.1.22/galfakeimg.php" "http://127.0.0.1/gallery" NOTE: If there are no albums with public permissions to add photos and you have a valid login, modify the script adding your login cookie.
web-apps please verify this and produce an updated ebuild if this is an issue.
It does look like gallery is vulnerable, although the posted proof-of-concept code doesn't run for me. I've attached a patch which should close the problem. Renat, could you put the webapp-based gallery ebuild into Portage, and include this patch in that? That'd be great. The exploit looks like it relies on the php.ini setting "allow_fopen_url" being set to "on". Without that setting, I can't see how an unpatched gallery would be vulnerable to this exploit. Best regards, Stu
Created attachment 37695 [details, diff] Diff to close the hole
gallery-1.4.4-r1.ebuild in CVS
Thx Renat. Arches please mark stable.
stable on ppc
Stable on sparc
Stable on alpha.
The patch introduces a parsing error when trying to upload photos via the "Form" method. After browsing for the pic(s) and hitting "Upload Now," the error displayed is (server name editted out to protect the innocent): ===================================================================== Parse error: parse error, unexpected '{' in /var/www/SERVERNAME/htdocs/gallery/save_photos.php on line 134 ===================================================================== Specifically, the third line added by the patch (the one that contained "!acceptableFormat") needs one more ")" at the end.
Back to ebuild status. Stuart or Renat please fix this?
Gallery v1.4.4-pl1 has been released to adress the issue: http://gallery.menalto.com/modules.php?op=modload&name=News&file=article&sid=134
I've posted a trivial patch to 1.4.4-pl1 at Bug #61164.
My dev box is down, and I don't know when it'll be back. Stuart, please do this if you have time.
stable on x86, and I've fixed the syntax error in the patch.
I submit that since the ebuild was marked stable on some arches with the bad patch, the ebuild rev should be bumped. Myself, I'm already using gallery-1.4.4_p1 (Bug #61164), so it doesn't matter to me personally.
Stuart please bump to r2 so users will pickup the correct version.
**bump** web-apps please bump to -r2 the GLSA is ready. **bump**
Stable on hppa.
p2 is now in cvs
This one is ready for GLSA. Security please review the draft.
web-apps please confirm or clarify our workaround: Move the temporary directory out of the webroot. It is also advisable to disable upload rights to all albums to "EVERYBODY". Lastly this exploit does not effect users with "allow_fopen_url" set to "off" in php.ini. Also what is the defaults for these settings in a normal install?
From the gallery website: Am I vulnerable? Chances are pretty good that you are not vulnerable to this security problem. The only way it can affect you is if:
From the gallery website: Am I vulnerable? Chances are pretty good that you are not vulnerable to this security problem. The only way it can affect you is if: the Attacker has upload rights to an album (either via EVERYBODY, or other rights) your Gallery temp directory is located inside the webroot. (Unusual, but not that out of the ordinary) URL wrappers are enabled Gallery is in debug/devMode or PHP is set to always display error messages By default: - upload rights to a new album are off - no temp gallery (the user has to explicitly specify it, and /tmp is given as an example) - no idea about URL wrappers - debug and dev mode are off, don't know about error messages - also, ask Stu about allow_fopen_url in php.ini Thus, workaround: - turn off upload rights to everybody - move temp dir out of webroot - turn off debug/dev mode - set php to not always display error messages - turn off allow_fopen_url in php.ini Makes sense?
GLSA 200409-05
