pluginvulnerabilities

It looks like there was an attempt to fix the vulnerability, but it didn’t fully resolve the issue. Are you still working with the developer to try get this fully resolved at this time?

It looks like you have found vulnerabilities in several other plugins as well, are you going to be disclosing the details of the vulnerabilities you have found somewhere after they are fixed?

Administrator-level users are normally permitted to use the equivalent of cross-site scripting (XSS) due to them having the unfiltered_html capability, so what they can do there wouldn’t be a vulnerability.

This could be considered a bug though and it looks like the plugin could be changed to prevent the issue from happening without it causing any problems.

Since that file should contain the contents of your database, that is likely either a false positive or you already had something malicious contained in your database. Unless whatever produced that result is designed to scan database backups, it would seem more likely to be a false positive. Have you checked with the source of that message to confirm that it is not a false positive?

That page is only accessible to Administrator-level users and they normally are permitted to use the equivalent of cross-site scripting (XSS) due to them having the unfiltered_html capability, so them being able to do what is mentioned here wouldn’t be a vulnerability on its own. If that could be combined with cross-site request forgery (CSRF) when saving those values then there would be a vulnerability, but CSRF is prevented with proper use of a nonce. So there doesn’t look to be a vulnerability here, but it does look like it could be considered a bug.

• This reply was modified 8 years, 1 month ago by pluginvulnerabilities.

@ov3rfly

Years ago we pointed out to them that it isn’t a good idea to hide vulnerabilities for the reasons you mentioned, but it clearly didn’t have an impact. Unfortunately, when it comes to security, especially of plugins, the people handling it for WordPress often seem to have a problem realizing the fairly obvious. They so far have also shown little willingness to listen to input that they are getting things wrong, which leads to problems continuing.

There is fair amount we are able to do when it comes to plugin vulnerabilities; like making sure they are aware of publicly disclosed vulnerabilities, making sure that vulnerabilities that haven’t been publicly disclosed, but are being exploited, are reported to them if the developer doesn’t respond, making sure that vulnerabilities actually have been fixed when they return them to the Plugin Directory, providing people an option to be alerted if they are using plugins that are being exploited with our plugin, but the rest is in their hands and that is where the problems continue to occur.

@trec-r

Delisting is a very good idea, as we have frequently found that it is the only thing that gets developers to fix vulnerabilities (including ones that are already being exploited) and if another vulnerability is reported to the developer subsequent to that, they will often deal with it in a timely manner without having to involve the people running the Plugin Directory.

We suggested years ago that WordPress start alerting people when they are using plugins that have been removed from the Plugin Directory and provide at least a general reason why it was removed. Shortly afterwards they said they were working on that, but the more recent position has been that letting people know of vulnerabilities in plugins they use would be harmful.

@msimpson

We are not part of WordPress, so it isn’t our person and we can’t do anything about what they do. Our only involvement is frequently being the ones that notify them of security vulnerabilities in plugins.

• This reply was modified 8 years, 1 month ago by pluginvulnerabilities.

@msimpson

What you are saying here is not entirely accurate. The first attempt you made to fix this, with the release of version 2.10.29, did not fully resolve the originally reported vulnerability. We contacted you the day after you released it to inform you of the remaining issues and we also left a message on the thread about the vulnerability mentioning that we had contacted you several days afterwards. So if the plugin had been left up at that point, people would have been updating to a version that didn’t actually resolve that vulnerability and others could have been installing a plugin that was known to be insecure at that point.

We agree with you that review process done by WordPress before a plugin can return to the Plugin Directory needs improvement, as it can cause delays in getting fixed versions out, while at the same allowing plugins with vulnerabilities that have not actually been fixed to return.

@sheddocksleybaptistchurch

The advisory for the cross-site scripting (XSS) vulnerability mentions that the vulnerability impacts version 3.2RC1 to 3.6.2 of Securimage, so versions older than that would not be impacted. To be sure, we checked version 4.0.45 of this plugin and it doesn’t contain the vulnerable code.

The update doesn’t fully fix the issue. We sent an email to the email address you previously mentioned with more details on the remaining issues several days ago.