Bugzilla Bug 60742

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 an attachment (id=37695) [details]
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