Gallery 2.2.4 Security Fix Release

Just in time for the holidays, Gallery 2.2.4 is now available for download. This release fixes critical security issues, no new features have been added. Due to the severity of these issues users of all previous Gallery 2 versions are strongly encouraged to upgrade to version 2.2.4 as soon as possible! All issues addressed in this release were discovered through an extensive internal security audit.

Since 2.2.4 is a security release, it shares the same installation requirements as 2.2.3. If you haven't upgraded to 2.2.x yet, please review the Gallery 2.2 release notes for highlights of changes and the requirements. Read on for more details and upgrade instructions.

Upgrading Instructions

Upgrading is quick and easy

  • Users of Gallery 2.1 or earlier should review release notes for requirement changes and update all application files.
  • Users of Gallery 2.2 or later (2.2.1, 2.2.2 or 2.2.3) can use an update file to upgrade specific core files and then upgrade the affected modules via Downloadable Plugins.

Regardless of your Gallery's version, review the upgrading instructions for complete details.

Security Vulnerabilities

Gallery 2.2.4 addresses the following security vulnerabilities:

  • Publish XP module - Fixed unauthorized album creation and file uploads.
  • URL rewrite module - Fixed local file inclusion vulnerability in unsecured admin controller and information disclosure in hotlink protection.
  • Core / add-item modules - Fixed Cross Site Scripting (XSS) vulnerabilities through malicious file names.
  • Installation (Gallery application) - Update web-accessibility protection of the storage folder for Apache 2.2.
  • Core (Gallery application) / MIME module - Fixed vulnerability in checks for disallowed file extensions in file uploads.
  • Gallery Remote module - Added missing permissions checks for some GR commands.
  • WebDAV module - Fixed Cross Site Scripting (XSS) vulnerability through HTTP PROPPATCH.
  • WebDAV module - Fixed information (item data) disclosure in a WebDAV view.
  • WebDAV module - Bug fix for directory listing issue (not security related).
  • Comment module - Fixed information (item data) disclosure in comment views.
  • Core module (Gallery application) - Improved resilience against item information disclosure attacks.
  • Slideshow module - Fixed information (item data) disclosure in the slideshow.
  • Print modules - Fixed information (item data) disclosure in several print modules.
  • Core / print modules - Fixed arbitrary URL redirection (phishing attacks) in the core module and several print modules.
  • WebCam module - Fixed proxied request weakness.

Lessons Learned

Gallery 2 has had an excellent security track record and the Gallery team continues to be committed to delivering a secure application. We are taking the following actions to improve our security audit process:

  • Allocating a larger budget for future external security audits to ensure that auditors gain a deeper understanding of the application to enable them to better identify issues.
  • Improving internal security review guidelines and checklists to ensure high standards in all code reviews, both internal and external.
  • Changing the API in the next major release of Gallery 2 to make it easier to write secure code.
schultmc's picture

Version 2.2.4-1 of the Debian gallery2 package was uploaded in the morning (EST) of Monday, December 24, 2007 and should be available in Debian unstable as of the archive push in the afternoon (EST) on Monday, December 24, 2007.

Debian gallery package maintainer

Releasing critical security update during holidays is not very clever. Thanks to Lubomir Kundrak who made this update to Fedora.

pyxel wrote:
Releasing critical security update during holidays is not very clever. Thanks to Lubomir Kundrak who made this update to Fedora.

Anytime during the holidays would have been a bad time. Although there haven't been any reports and even though we've discovered these issues internally, we have to assume that bad guys know about some of these issues already. The severity of the vulnerabilities didn't leave us much choice but to release the fix as soon as possible.

Sorry for the inconvenience and the timing. Sometimes all alternatives have bad implications. We opted for the solution that would protect our users the best.

valiant wrote:
Sorry for the inconvenience and the timing. Sometimes all alternatives have bad implications. We opted for the solution that would protect our users the best.

I understand, thank you for the fix and have a nice holidays!

pyxel wrote:
Releasing critical security update during holidays is not very clever.

1. Waiting to release critical security updates is even less clever. In fact it is almost not very responsible. Thanks to the team for caring about my systems and client's systems enough to do this.

2. Figuring out how to politely leave the church or party, during the holidays, to fix a compromised system would be clever.

Of course now I have several clients I gotta go upgrade!

nicos's picture

I see some coming changes in the API, how big will these be? Perhaps better to wait before starting using this for my new apps?
Just another Geld Lenen story!

nicos wrote:
I see some coming changes in the API, how big will these be? Perhaps better to wait before starting using this for my new apps?

All API changes for the next major release (G2.3, spring 2008) are backwards compatible.
You can review the API changes at: development -> API -> Changes since last release.

For G2.4 (late 2008?) we'll introduce major non backwards compatible changes. We'll drop PHP 4 compatibility in favor of using more of PHP 5's features, add a type-safe input filtering framework and much more.

bigu_c's picture

Thank you very much!

Is ISO-8859-2 charset coding already supported in this release?

what are the planned features/changes for G2.4 ?

serbanc -

bigu_c's picture
serbanc wrote:
what are the planned features/changes for G2.4 ?

serbanc -

Securities fixed only!

Read carefully introduction please!

floridave's picture

General roadmap:
No plans for 2.4 yet but here is 2.3 roadmap:


Blog & G2 || floridave - Gallery Team

floridave wrote:
here is 2.3 roadmap:

The schedule part is missing the steps between polishing and releasing:


* The feature freeze should be 3 to 6 months from now (rather 3): Features freeze ~July 30th, 2007.
* 1.5 to 2 months of testing, bugfixing and polishing after the feature freeze

Should this be updated? Removed and a pointer to a master schedule inserted?

thx, guys.
I propose two issues for the next releases.

1. system links. posibility to have more than one "system link" - aka menubars. Ex. by default, a module registers in systemlinks (to keep compatibility), but an admin can move it in another system link - read menubar.

2. sidebar - have all the itemlinks available in sidebar and not hardcoded in core module. Integrations with 3'rd party are going to be happy.

serbanc -

floridave's picture

please add feature requests to the proper location, not a news story.

Blog & G2 || floridave - Gallery Team

serbanc -

Thanks for the security its really good . I have two questions for the next releases

1)Is ISO-8859-2 charset coding already supported in this release?
2)what are the planned features/changes for G2.4 ?


> 1)Is ISO-8859-2 charset coding already supported in this release?

no. UTF-8 (unicode) is a superset of ISO-8859-2 and the general direction of web applications is towards unicode.

> 2)what are the planned features/changes for G2.4 ?

see: development -> roadmap (upper right corner).

Documentation: Support / Troubleshooting | Installation, Upgrade, Configuration and Usage

My webserver was successfully hacked, through a hole in Gallery 2.0

I'd like to document this successful hack of my dedicated server, not to whine but to describe how the hack was carried out and how other webmasters can both detect and correct a hacked system successfully. Three months elapsed between the hack of my system and its mal-use that caused a shutdown. If I had known any of the markers I'm about to describe to you during those three months, I could have fixed my system before 30 domains went down hard.

1. An over-long URL was sent to the "main.php" module of Gallery 2.0
2. This allowed the hackers to execute code in Front-Page, also on my server
3. The MS-Frontpage code, "fpexe", runs as root and can do anything
4. fpexe was used to create a user account at the Linux level
5. The hacker logged on to port 22 (SSH) using this account
6. The hacker then waited 3 months before "selling" my hacked server to a phishing gang
7. The phishing gang then logged onto port 22, downloaded some bot code written in PHP, and ran it continuously
8. The bot code connected to IRC servers in Romania and Russia, then put up a fake banking website

1. Scan the "access_log" file (usually in /var/log/httpd) for overly-long GET requests to "main.php" in the gallery directory. Here is a sample:
Received From: u15291219->/var/log/httpd/access_log
Rule: 31115 fired (level 13) -> "URL too long. Higher than allowed on most browsers. Possible attack."
Portion of the log(s): - - [15/Mar/2008:13:34:10 -0700] "GET /gallery/main.php?g2_view=core.UserAdmin&g2_subView=core.UserLogin&g2_return=%2Fgallery%2Fmain.php%3Fg2_view%3Dcore.UserAdmin%26g2_%253Bg2_subView%3Dcore.UserRecoverPassword%26g2_%253Bg2_return%3D%252Fgallery%252Fmain.php%253Fg2_view%253Dcore.UserAdmin%2526g2_%25253Bg2_subView%253Dcore.UserLogin%2526g2_%25253Bg2_return%253D%25252Fgallery%25252Fmain.php%25253Fg2_view%25253Dcore.UserAdmin%252526g2_%2525253Bg2_subView%25253Dcore.UserRecoverPassword%252526g2_%2525253Bg2_return%25253D%2525252Fgallery%2525252Fmain.php%2525253Fg2_view%2525253Dcore.UserAdmin%25252526g2_%252525253Bg2_subView%2525253Dcore.UserRecoverPassword%25252526g2_%252525253Bg2_return%2525253D%252525252Fgallery%252525252Fmain.php%252525253Fg2_view%252525253Dcore.UserAdmin%2525252526g2_%25252525253Bg2_subView%252525253Dcore.UserLogin%2525252526g2_%25252525253Bg2_return%252525253D%25252525252Fgallery%25252525252Fmain.php%25252525253Fg2_view%25252525253Dcore.UserAdmin%252525252526g2_%2525252525253Bg2_subView%25252525253Dcore.UserLogin%252525252526g2_%2525252525253Bg2_return%25252525253D%2525252525252Fgallery%2525252525252Fmain.php%2525252525253Fg2_view%2525252525253Dcore.UserAdmin%25252525252526g2_%252525252525253Bg2_s

2. Look for entries in "suexec_log" in /var/log/httpd indicating that the Apache server executed root commands
3. Look in /etc/passwd for new user accounts
4. Look in /home for new user home directories

1. Installed Gallery 2.4
2. Uninstalled Frontpage and deleted "fpexe"
3. Disabled Port 22 logins except from a single account, which I must use
4. Disabled password access on SSH, allowing only pre-shared AES private/public keys
5. Went into php.ini and disabled a bunch of PHP function calls that only hackers would use (like "fsockopen", used to talk on IRC to Russia)
6. Installed Mod_Security into Apache
7. Upgraded to the latest Linux
8. Upgraded to the latest Apache
9. Upgraded to the latest MySQL
10. Installed mod_evasive into Apache, to prevent DDOS attacks
11. Got a hardware firewall, separate from the server and tightened the ports both in and out to ones I use
12. Turned off all unnecessary Linux services, such as SMTP, MAIL, and BIND
13. Installed OSSEC, which continually monitors all logs and notifies me when any security breach is attempted
14. Turned on the OSSEC feature which blocks specific IP addresses which try to hack the system (via multiple bad logins, URL exploits, etc.)
15. Considerably tightened MySQL security by partitioning logins to specific databases and tightly limiting rights.

Don't take Menalto's warning to upgrade to version 2.4 lightly. They hackers from around the world know all about this hole. Using my new
monitoring system I've seen three different attempts made to hack my Gallery 2 (from Korea, Russia, and Brazil) this weekend. They are on
this like fleas. If I can encourage or advise anyone, I will do so. Don't let this happen to you.

Thanks for sharing this story. I agree that one shouldn't ignore security fix releases of any software. But what makes you think that this had anything to do with Gallery 2? Your description in "HOW TO DETECT THEIR TRACKS" rather looks like a vulnerability in the webserver. The G2 URL itself doesn't do anything special in G2. It's a request for a login page, it's not even a login request. Just for a HTML page. But the length of the URL could cause some buffer-overflow in the webserver if the webserver is vulnerable in that regard. Which is not related to G2.

And by the way: It's Gallery 2.2.4 and not 2.4. :)

Good questions, let me explain:

* The recent logging of G2 hack attempts indicates that hackers are attempting it systematically and globally, not the particular request string used to compromise my system four months ago. Since in two days three different hackers (from Russia, Germany, and Korea) used this exact same string overload only on G2 and no other domain of my 30 indicates some specific worldwide attempt against G2. This is not one lone hacker idly trying random possible vulnerabilities but a shared exploit that many are trying.

* Yes, it's possible that this specific exploit might work against other vulnerabilities but consider this:
1. My security logs don't show any instance of it except in a G2 context, to a G2 subdir
2. The parms in it are G2 parms, not just random text
Ergo, my conclusion that this attack is G2-focused.

* The specifics of the FrontPage execution log pointed directly to a site of mine, from a G2 directory. Hence my feedback that G2 was used to run "fpexe", which was used to create a user account.

* The hackers find Gallery2 sites by using Google. They use "Google Dorks" which are Google search strings which return a list of sites using Gallery. Those G2-installed sites are then scanned for attack. Here is an excerpt on a hacker website where these "GD"s are discussed, including one to find sites with Gallery:

* The good news is that zero hack attempts have gotten to first base since I upgraded G2. All my other security measures were icing on the cake since the upgrade locks the front door that they are pounding on. "Wake up webmasters; listen to the G2 sysop. Upgrade your old G2 systems!"

* Yes, I know the version is 2.2.4, but the comment posting system didn't allow me to change it once submitted. There's another typo too; the substitution of "they" for "the".

* I have zero complaints. Security is MY responsibility as webmaster. The G2 upgrade notices were clearly posted hence the authors did their duty. My goal is to impart to others the need to listen to G2 upgrade notices and spare others server rebuilding as a consequence of server penetration.

I still fail to see why G2 is related to the issue. The one URL you posted in your comment is the following:


G2 really does nothing but show a login page for that request. It doesn't do further processing, it doesn't create files and it doesn't change anything in the database for that request.

The primary question is how the attacker could place some files on your server. And how the uploaded content/file could be executed. And how it could be executed in root context.
For G2, only the first two questions are relevant, if at all. G2 shouldn't allow something like that. And to see if G2 or another application was responsible for allowing the attacker to execute some unauthorized code on your server one needs to analyse the logs.
All I say is that while there may be other log entries that could explain how this was accomplished, the one URL you've shown doesn't explain anything. :)

So it may well be that applying the (security) updates for your whole system might not have been the icing on the cake but the actual fix. Either way, the Gallery 2.2.4 security patch release was very important and the kind of vulnerabilities in prior G2 versions were pretty bad.

Documentation: Support / Troubleshooting | Installation, Upgrade, Configuration and Usage

I've given you enough material to detect similar attacks on your own system, and to protect it. You'll have to do your own research from here. This is what I know:

* A hacker exploit against G2 was used to run FrontPage's "fpexe" module
* fpexe, when installed in Apache, runs as root in Linux. Look up this exploit to understand it better:
* Hackers are currently running attempts on my G2 system, as I documented.
* I don't understand exactly how/what their hacks do.

I also see similar attemps on my g2 server too. my question, is only g2 is aimed at or any other software, too. I only use wordpress & gallery and I see hits similar to above on g2 only.

Constant attacks on any web application are normal. I'd start getting curious if you see that a specific application is targeted and if the URLs look like they could be doing something. An absurdly high percentage of these automated "attacks" are attempts to post spam or phishing redirects. So they're harmless and Gallery 2.3 is doing a far better job at rejecting spam comments than previous Gallery versions.

It's just important to stay ahead of the game. Our job as developers is to make the application as robust as possible and your responsibility as users is to subscribe to the announcement mailing lists of the applications you use such that you get notified of upgrades as fast as possible.

bharat's picture

Thanks for the very detailed information! It's good for us to see the types of attack vectors that black hats are using to try to compromise our systems. I am seeing a constant flood of these types of attacks on my Gallery also. If you believe that you've been hacked, please contact us at [url][/url] ASAP and we'll do forensics on your system with you.

Short of a buffer overflow vulnerability in Apache or PHP, I don't see how the URL you provided triggered the vulnerability. I've been over that part of the code very carefully, just in case. Could you provide us with some more possible attack vectors? I wonder if there's another one in there that we're overlooking. I'd pay special attention to POST requests because the payload of those is not generally saved in your logs. Any further information you can provide on the attack vector would be very useful to us. Even if it's not a G2 related issue, it's good for us to know about other attacks in the stack that Gallery2 uses.

Hello Bharat,

Thanks for writing, it's cool to talk to the brilliant author who has given us this terrific photo album. Let me say thank you.

It's very possible that the attacks I've seen lately are completely ineffective, yet I see them only because they trigger OSSEC, my log-scanner software. His rule-set may well ring the alarm when it shouldn't, yet not notify me when it should. As the soldiers say: "It's the bullet you don't hear that gets you".

I'm in a submarine and this is my little periscope yet it's better than going blind like I did before. I'll look at other error logs (I'm running Mod_Security under Apache) and report in if I can find other G2 attack vectors that don't trigger OSSEC. I have no idea if this method is how they originally penetrated my system, using G2 to execute FrontPage's "fpexe", then creating a Linux user, then logging into SSH.

Ineffective or not, this alert gets emailed to me 2-3 times daily, as hackers from around the world try it. It's probably a standard item in some hacking script. The URL is over 8192 bytes, possibly a buffer-overflow attempt. Here's a recent log alert, this time from an Italian source:

-------------------------------start log-----------------------------
OSSEC HIDS Notification.
2008 Mar 19 19:09:27

Received From: u15214219->/var/log/httpd/access_log
Rule: 31115 fired (level 13) -> "URL too long. Higher than allowed on most browsers. Possible attack."
Portion of the log(s): - - [19/Mar/2008:19:09:26 -0700] "GET /gallery2/main.php?g2_view=core.UserAdmin&g2_subView=core.UserRecoverPassword&g2_return=%2Fgallery2%2Fmain.php%3Fg2_view%3Dcore.UserAdmin%26g2_%253Bg2_subView%3Dcore.UserRecoverPassword%26g2_%253Bg2_return%3D%252Fgallery2%252Fmain.php%253Fg2_view%253Dcore.UserAdmin%2526g2_%25253Bg2_subView%253Dcore.UserLogin%2526g2_%25253Bg2_return%253D%25252Fgallery2%25252Fmain.php%25253Fg2_view%25253Dcore.UserAdmin%252526g2_%2525253Bg2_subView%25253Dcore.UserLogin%252526g2_%2525253Bg2_return%25253D%2525252Fgallery2%2525252Fmain.php%2525253Fg2_view%2525253Dcore.UserAdmin%25252526g2_%252525253Bg2_subView%2525253Dcore.UserRecoverPassword%25252526g2_%252525253Bg2_return%2525253D%252525252Fgallery2%252525252Fmain.php%252525253Fg2_view%252525253Dcore.UserAdmin%2525252526g2_%25252525253Bg2_subView%252525253Dcore.UserLogin%2525252526g2_%25252525253Bg2_return%252525253D%25252525252Fgallery2%25252525252Fmain.php%25252525253Fg2_view%25252525253Dcore.UserAdmin%252525252526g2_%2525252525253Bg2_subView%25252525253Dcore.UserRecoverPassword%252525252526g2_%2525252525253Bg2_return%25252525253D%2525252525252Fgallery2%2525252525252Fmain.php%2525252525253Fg2_view%2525252525253Dcore.UserAdmin%25252525252526g2_%2
---------------------------end log-------------------------------------

Hmm it seems to try exploiting any bug for the admin password recovery. Hope there is no bug and the "hacker" doesn't have any success.. :)


My WebSite


After much pain I have installed and set up G2 in J!1.5.

I can't get the CB plug in to work but I figured I didn't need is as I am trying to create quite a closed system.

I installed:
g2bridge_component v2.2

I have added a test album and created a menu link to it in Joomla.

I can see the album and thumbs but when I click on the image it jumps to the main page.

see site below and navigate to the test gallery page

this is the G2 installation


net4earning's picture

the conversation between waltbru and valiant is quite helpful.