anotherdave

Hi Matt,

Thank you very much for responding.

Sorry I wasn’t as detailed / clear in the original post – I am the host. I’ve been running a small hosting service since 1996 (before Godaddy and Google even existed) and I started hosting WordPress sites in early 2004. Currently about 200 of the web sites I host are customers using WordPress, many of which I installed WP for them and several of which I do the basic WordPress maintenance for (since many users either aren’t aware that they need to keep WP and Plugins / Themes updated or are afraid to do it themselves). Many of them have very extensive sets of Plugins installed and no issues.

The ModSecurity ruleset in use on my servers is the common one that is built into the latest version of cPanel/WHM 11.56 – COMODO ModSecurity Apache Rule Set , latest version 1.87 – and you can see the complete ruleset at https://waf.comodo.com/user/cwaf_revisions (you can also download the ruleset there, with a free account).

If you have root admin access to a cPanel server running cPanel/WHM 11.48 or higher, you can log in to WHM and then go to Security Center > ModSecurity Vendors to view / enable / disable / edit the ruleset just like you can see in this old thread on the Comodo forums from over a year ago when the Comodo WAF rulset was first integrated and implemented by cPanel – https://forums.comodo.com/free-modsecurity-rules-comodo-web-application-firewall/comodo-as-a-modsecurity-vendor-in-cpanel-t110147.0.html

Given the fact that the CVE is from 2012 and the rule being triggered by Give is:

[id “220030”] [rev “2”] [msg “COMODO WAF: Vulnerability in PHP before 5.3.12 and 5.4.x before 5.4.2 (CVE-2012-1823)

It’s possible that it’s a false positive due to some older syntax mixed in with your plugin, but either way it will still cause users on servers running the latest version of cPanel with the latest version of Comodo WAF ModSecurity for Apache to run into problems and/or get blocked from their server when they attempt to access their WP Admin Dashboard with Give installed / enabled.

I followed your suggestion and downloaded the zip file of the icomoon fonts that you’ve provide at https://www.dropbox.com/s/ti2biwyeoa5e3hk/give-fonts.zip?dl=0 and then unzipped / uploaded them to the /wp-content/plugins/give/assets/fonts/ folder (overwriting the existing ones already there). I then re-enabled ModSecurity rule ID 220030 on the user’s account and logged into his WP admin Dashboard, and it still triggers the rule.

I’m disabling the Give plugin on the user’s account for now so that they can log in to their Dashboard without getting firewalled and letting them know that I’m working with you to find a better solution than disabling the ModSecurity rule.

By reading through your support forum here I can see that you are a responsive developer who actually cares about your plugin, so kudos for that! Since I host hundreds of WordPress sites I have to deal with a lot of plugins on behalf of customers and I wish all of them cared about their product as much as you do.

In fact, I would be more than happy to set you up with a test hosting account on one of my servers with a clean fresh installation of WordPress for you to experiment with in my very modern server environment, and would be happy to work directly with you on this if you’d like. If you’re interested just send me a private message with your direct email and I’ll contact you via my direct email (and phone if you’d like) since I do not post my company information here on the WordPress.org forum (mainly because I think it would break the rules & possibly considered spam, but also because you know I’d have everyone on the forums contacting me for support day & night).

It would be great to work with you directly outside of this forum, so just shoot me a private message if you’re interested. It would be good for both of us – for you because I can give you a real-time troubleshooting environment to assist you with this, and for me because we could eventually resolve this issue for my customer using your plugin 🙂

Side note – I’m preparing to upgrade the native PHP from 5.5 to 5.6 on all of my servers, but I do have the ability to set individual accounts to any version from PHP 5.4 to PHP 7 for testing purposes. Nice for development / troubleshooting.

Hope to speak with you soon,
Dave

UPDATE – I was wrong about there being no mod_security issue.

In fact, I was looking at the wrong server’s mod_security log when I started this thread.

However, I did in fact discover an incompatibility between Mojo Under Construction and Comodo’s mod_security rule ID 214560

As follows from the server mod sec log:

(I’ve replaced the actual site domain with example.com for security purposes)

[Fri Jan 08 21:44:49.445538 2016] [:error] ModSecurity: Access denied with code 403 (phase 4). Pattern match “(?i)(String\\\\.fromCharCode\\\\(.*?){4,}” at RESPONSE_BODY. [file “/usr/local/apache/conf/modsec_vendor_configs/comodo_apache/14_Outgoing_FilterGen.conf”] [line “28”] [id “214560”] [rev “1”] [msg “COMODO WAF: Potential Obfuscated Javascript in Output – Excessive fromCharCode”] [data “Matched Data: String.fromCharCode(55356,56806,55356,56826),0,0),d.toDataURL().length>3e3):\\x22diversity\\x22===a?(e.fillText(String.fromCharCode(55356,57221),0,0),c=e.getImageData(16,16,1,1).data.toString(),e.fillText(String.fromCharCode(55356,57221,55356,57343),0,0),c!==e.getImageData(16,16,1,1).data.toString()):(\\x22simple\\x22===a?e.fillText(String.fromCharCode( found within RESPONSE_BODY: <!DOCTYPE html>\\x0a<!–[if IE 8]>\\x0a<html xmlns=\\x22http://www.w3.org/1999/xhtml\\x22 class=\\x22ie8 wp-toolbar\\x22 …”] [severity “CRITICAL”] [hostname “example.com”] [uri “/wp-admin/index.php”]

[Fri Jan 08 21:44:49.446001 2016] [:error] ModSecurity: Warning. Operator GE matched 4 at TX:outgoing_points. [file “/usr/local/apache/conf/modsec_vendor_configs/comodo_apache/21_Outgoing_FiltersEnd.conf”] [line “38”] [id “214940”] [rev “1”] [msg “COMODO WAF: Outbound Points Exceeded (points 5)”] [hostname “flavorpull.com”] [uri “/403.shtml”]

Disabling COMODO mod_security rules makes the issue go away, but also removes the added security provided by COMODO mod_security.

Any ideas from your side?

I’m happy to help with testing if you like.

Thank you Cais!

I do know of some friends and colleagues whom are watching this thread instead of creating new / redundant versions of it, so I’m just going to post this update here for their benefit.

I received your Bug Report response along with the modified package.module.nextgen_data.php file to upload to ../wp-content/plugins/nextgen-gallery/products/photocrati_nextgen/modules/nextgen_data

I’ve tested everything thoroughly after uploading it.

Here’s what it fixed for me in regard to only the issues I’ve encountered with NGG:

1. The warning – “PHP Warning: getimagesize(1): failed to open stream: No such file or directory in /home/xxxxxxxx/public_html/hdwp/wp-content/plugins/nextgen-gallery/products/photocrati_nextgen/modules/nextgen_data/package.module.nextgen_data.php on line 656” – is gone now when uploading images.

2. When I go to Dashboard > Gallery > Manage Galleries and click on a gallery, then select all images within it, then use the drop-down Delete option, it does actually remove the images (but not the folders) from the server and also proportionally changes the number of Images listed at Dashboard > Gallery > Overview

3. When I go to Dashboard > Gallery > Manage Galleries and select a gallery and then delete it, it does actually proportionally change the number of Galleries listed at Dashboard > Gallery > Overview (but does not remove the related folders from the server)

Here’s what it does not fix:

1. When I go to Dashboard > Gallery > Manage Galleries and select a gallery and then delete it, it does not remove image files from the server (as you mentioned you’re already aware of, and there is not yet a fix for)

2. None of the delete functions remove the related gallery folders (such as the individual gallery folders and the sub-folders /thumbs and /dynamic) from the server.

Here’s something strange / new that I noticed:

1. NGG now creates a folder named “dynamic” in the main folder where WordPress installed, instead of just in the individual /wp-content/gallery/galleryname/ folders. (Not sure if it’s meant to do that now,

that any plugin like this would create a new folder right in the root of the WordPress install rather than just within the plugin’s related folders themselves in wp-content).

Thanks again for your reply and the modified file and your help!

I’ll keep an eye out for updated versions to see if the remaining issues are resolved and will update this thread for the benefit of my friends whom are following it.

Actually, since this is becoming more and more important I’ve made the time to do this today.

I just did a completely fresh new WordPress install in a new folder call hdwp in the hosting account did nothing but the most basic settings and added a common construction plugin and the latest NGG plugin right from within Dashboard > Plugins.

Then I:

1. added a test page called Gallery Test Page to Dashboard > Pages.

2. created a gallery inDashboard > Gallery > Add Gallery / Images called Mixed Images in NGG and uploaded 10 test images to it.

3. added that gallery to the test page via the NGG button in the page editor.

At this point, the PHP error_log file in the new WordPress folder already shows 10 instances of the following PHP warning. Assuming 1 instance for each image uploaded:

PHP Warning: getimagesize(1): failed to open stream: No such file or directory in /home/xxxxxxxx/public_html/hdwp/wp-content/plugins/nextgen-gallery/products/photocrati_nextgen/modules/nextgen_data/package.module.nextgen_data.php on line 656

(no PHP error_log in the wp-admin folder at this point, just the WordPress public side folder /hdwp)

So then I:

1. Deleted the gallery from the test page.

2. went to Dashboard > Gallery > Overview and confirmed that it showed the 10 images and 1 gallery still listed / in-tact.

3. went to Dashboard > Gallery > Manage Galleries and selected the check box next to the gallery, chose Delete from the drop-down menu, clicked Apply.

That removed the test gallery from Dashboard > Gallery > Manage Galleries , but:

1. It did NOT remove the “10 Images” from Dashboard > Gallery > Overview

2. It did NOT remove the mixed-images folder from wp-content/gallery

3. It did NOT remove the image files, nor the backup image files, nor the thumbs.

Note – At this point there are no errors in the server’s Apache error log nor in the cPanel error log, and no error_log file in the w-admin folder. The only errors that can currently be seen are the original 10 PHP Warnings (during the 10 image uploads) for package.module.nextgen_data.php in the PHP error_log file that the server generated in the main folder where this new clean test WordPress is installed.

Cais,
I’ll leave it alone now and head over to http://nextgen-gallery.com/report-bug/ to provide with full Administrator access to the WordPress install and full FTP / cPanel / mySQL / phpMyAdmin access to the hosting account in just a few minutes.

Uninstalling the NGG plugin also leaves a TON of stuff behind in the database to be manually cleaned up. I can see how, in it’s current state, if someone uses it for a lot of images and then decides to switch away from it they’re going to accumulate a bunch of files in their hosting account and have a lot of cleanup to do in their database. I really don’t mean to knock this plugin but I’m just pretty surprised at just how much seems to be wrong with it behind the scenes. One could easily end up with thousands of junk rows and indexes in their DB tables as well as many files on their server that they might not realize are there (especially users who don’t FTP in to check folders and phpMyAdmin in to check the DB tables).

POSSIBLY SOLVED ALREADY:

I took a chance and though to just briefly rename the second WP folder from /blog to /old_blog just to see what might happen (knowing I could quickly rename it back) and that seems to have resolved the issue!

I’m going to do some testing now and check the PHP error_log files on the server and other error logs (such as cPanel) to see if there are any detrimental affects, other than possibly having to ditch the old blog in favor of keeping the new one working right. (Person I’m helping was hoping to keep both).

Thanks VERY much to anyone who took the time to read this.

I’m still open to responses and opinions if anyone cares to provide input.

Thank you!