Security in Gallery 2.3.1

Is there anyone in particular I should contact about security concerns with Gallery 2.3.1? I tried asking on IRC, but I'm not sure anyone was watching the channel at the time. I have seen a few attempts to hack my gallery in the last few days, and I'd like to make sure not only that they were unsuccessful, but that whatever holes they were trying to exploit either get fixed or already have been. Only some of the attempts show up in my Gallery Event Logs, which makes me nervous about the attempts that don't.

Here is one which did make it into the Event Logs. I've replaced the URL listed with "URL_GOES_HERE" in both cases.

Error (ERROR_BAD_PARAMETER) : URL_GOES_HERE can't be parsed in modules/core/classes/GalleryView.class at line 149 (GalleryCoreApi::error)
in main.php at line 325 (GalleryView::loadView)
in main.php at line 104
in main.php at line 88

Request variables: Array
(
[view] => URL_GOES_HERE
)

The target URL contains the following:

<?php echo md5("just_a_test");?>

As I mentioned, I see other attempts in my httpd access_log which do not show up on the Gallery Event Logs. I'd be happy to share that information with whoever handles security for Gallery, but I'd prefer to not do so on a public forum.

Any website on the web will be tested by potential hackers and a web application cannot log all such attempts. For a start, many of them will never reach the application itself for various reasons.

The attempt you have noted is trying to see if Gallery2 will execute php scripts passed to it as url arguments. It obviously doesn't as that would be very bad coding. You may not be aware but security wise, the Gallery scripts starting from G1 stand heads and shoulders above all the competition. In over ten years and hundreds of thousands of deployments, there have been only a handful (less than five I think) of potential exploits identified and no actual breaches recorded.

However 3rd party modules just might be vulnerable especially if they access PHP methods directly instead of going through G2 API.

Having said all that however, the error message you posted points at a problem with your server. A basic probe of your site such at that above should not get past the first defenses on the server and should not even get to a PHP application running on the server in the first place.

Server security has many layers and the best approach is to have server level defenses that assume that you cannot rely on the applications running on the server to be well written.
You can try to visit my site for instance and try to pass that parameter and see what happens: http://www.dakanji.com/imagery/?test=%3C?php%20echo%20md5%28%22just_a_test%22%29;?%3E (The gobblygook is just <?php echo md5("just_a_test");?> with url escaping)

Don't stop there. Try to visit another normal page after: http://www.dakanji.com/imagery/albums/scenics and you will have been barred from further visits for a period of time.

If you run your own server and use Apache, make sure you have Mod_Security (ask your host if on a shared host why simple exploits are not picked up and whether they have mod_security active as they should). The ASL suite is great and I have used it in the past. You can also use PHPIDS yourself to screen PHP applications and not rely on your host.

I use Nginx and have written my own filter in Lua which catches such basic stuff using the Nginx Lua module. There is Naxsi which is an interesting security filter for Nginx.

There are also other tools such as BFD and similar which should be on every web server.

So basically, PHP and other applications should be well written, and G2 is one of those that are, to catch such exploits but as a webmaster, your best bet is to assume they are not and apply some basic server level security.

--
dakanji.com