13 Apr

Not Really a WordPress Plugin Vulnerability – Week of April 13, 2018

In reviewing reports of vulnerabilities in WordPress plugins we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we release posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular are items that are not outright false, just the issue is probably more accurately described as a bug. For those that don’t rise to level of getting their own post we now place them in a weekly post when we come across them.

Persistent Cross-Site Scripting (XSS) Vulnerabilities in WordPress File Upload

This week there were a couple of reports of claimed persistent cross-site scripting (XSS) vulnerabilities in WordPress File Upload that were supposed to have been fixed in version 4.3.3 and 4.3.4. For both of them, the proof of concept indicated that the claimed vulnerability would be exploited when logged in to WordPress. In testing things out it looked to us that you would need to be logged in as an Administrator to access them. That was confirmed by looking at the code. The page on which the issues occurred through is only accessible in the admin area of WordPress if the user has the “manage_options” capability:

21
if ( current_user_can( 'manage_options' ) ) $page_hook_suffix = add_options_page('Wordpress File Upload', 'Wordpress File Upload', 'manage_options', 'wordpress_file_upload', 'wordpress_file_upload_manage_dashboard');

Users with the “manage_options” capability would normally only be Administrators (and if others are given the capability they would normally be able to create Administrators accounts). Those users would normally have the “unfiltered_html” capability and therefore could do the equivalent of persistent XSS, so those issues wouldn’t really be vulnerabilities.

There also was already protection against cross-site request forgery (CSRF) in place for both of the issue, so there was not CSRF/XSS vulnerability that had existed either.

05 Apr

Real World Result of RIPS Code Analysis Service Doesn’t Match Hyperbolic Marketing of It

Recently there was claim made that an authenticated SQL injection vulnerability had been fixed in the plugin Custom Permalinks. In looking into that though we found that it was only accessible to Administrators, who would already normally have the capability to do the equivalent of SQL injection, so that wouldn’t really be a vulnerability. What seems notable about this is that the claim of the vulnerability came from the maker of an automated security tool that is marketed out of line with the actual result shown by that vulnerability claim.

The tool is marketed with claims like this:

RIPS code analysis detects critical security issues in your PHP application without false positive noise.

While we wouldn’t describe that issue as a false positive, it also is far from a critical security issue. The reality is that automated tools like that tool or are Plugin Security Checker have serious limits in what they can do (something that the rest of the marketing material for RIPS doesn’t give any hint of) and are best used by knowledgeable professionals that can properly integrate the results in to a larger security process.

The rest of the marketing just on its homepage is rather over the top as well, with phrases like “unique PHP analysis”, “most accurate”, “unmatched bug detection”, “precise detection”, “no other solution can find”, “leading performance”, and “in-depth security analysis”. None of that is linked to pages that attempt to back up the claims, which is less than reassuring about the capabilities of the tool and the people behind it.

What we found when we went to look in to this claim, backs up that concern, as a rather obvious security vulnerability actually exists in the functionality they claimed contained the authenticated SQL injection vulnerability.

While only Administrators could access that claimed vulnerability directly, it was still possible that there could be a way to exploit it if two conditions were met. The first being that there wasn’t protection against cross-site request forgery (CSRF) and that the request to exploit it was a GET request. The proof of concept provided for it ruled out that possibility since it involved a POST request:

Send authenticated POST request to “URL/wp-admin/admin.php?page=custom-permalinks-post-permalinks” with parameters “action=delete&permalinks[]=1) PAYLOAD — “

But that would seem to indicate that there wasn’t protection against CSRF, which in this case would mean that if an attacker could get a logged in Administrator to visit a URL the attacker controls they could cause permalinks created by the plugin to be deleted.

We first confirmed that was the case in a web browser and then we reviewed the underlying code to see all that was going on behind the scenes.

The plugin’s admin page PostTypes Permalinks is only accessible to those with the “administrator” role and accessing it calls the posttype_permalinks() function (in the file /admin/class-custom-permalinks-admin.php):

add_submenu_page( 'cp-post-permalinks', 'PostTypes Permalinks',
	'PostTypes Permalinks', 'administrator', 'cp-post-permalinks',
	array( $this, 'posttype_permalinks' )
);

Near the top of the function it checks if several POST inputs exists and if they exist it will delete the specified permalinks:

52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
public function posttype_permalinks() {
	global $wpdb;
	$filter_options   = '';
	$filter_permalink = '';
	$search_permalink = '';
	$html             = '';
	$error            = '';
 
	// Handle Bulk Operations
	if ( ( isset( $_POST['action'] ) && $_POST['action'] == 'delete' )
		|| ( isset( $_POST['action2'] ) && $_POST['action2'] == 'delete' )
		&& isset( $_POST['permalink'] ) && ! empty( $_POST['permalink'] ) ) {
		$post_ids = implode( ',', $_POST['permalink'] );
		if ( preg_match( '/^\d+(?:,\d+)*$/', $post_ids ) ) {
			$wpdb->query( "DELETE FROM $wpdb->postmeta WHERE post_id IN ($post_ids) AND meta_key = 'custom_permalink'" );

There is no check for a nonce, which would prevent cross-site request forgery (CSRF), before the deletion happens.

We notified the developer of the plugin of the issue on February 26 and they replied the next day that the issue would be fixed “ASAP”. Earlier today, for the first time since we contacted them a new version was released, but it didn’t make any change related to the vulnerability.

Proof of Concept

The following proof of concept will delete the permalinks with IDs 1 and 2, when logged in as Administrator.

Make sure to replace “[path to WordPress]” with the location of WordPress.

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/admin.php?page=cp-post-permalinks" method="POST" >
<input type="hidden" name="action" value="delete" />
<input type="hidden" name="permalink[]" value="1" />
<input type="hidden" name="permalink[]" value="2" />
<input type="submit" value="Submit" />
</form>
</body>
</html>

Timeline

  • February 26, 2018 – Developer notified.
  • February 27, 2018 – Developer responds.
08 Dec

Not Really a WordPress Plugin Vulnerability – Week of December 8, 2017

In reviewing reports of vulnerabilities in WordPress plugins we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we have been releasing posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular are items that are not outright false, just the issue is probably more accurately described as a bug. We have been thinking that providing information on why those are not included in our service’s data could be useful, so we are trying out putting a weekly post when that occurs detailing those issues.

Directory Traversal Vulnerability in WooCommerce

A lot of reports of vulnerabilities that turn out to be false at least seem to have a valid basis, but occasionally you have truly strange ones. The claim of a directory traversal vulnerability in WooCommerce falls into the latter category. The claim made is:

Identifying woo commerce theme pluging properly sanitized against Directory Traversal,even the latest version of WordPress with woocommerce can be vulnerable.

Directory traversal refers to the ability to move outside of a specified directory, it isn’t a vulnerability on its own, just something that could be a piece of a vulnerability. An example of where that could come in to play as a vulnerability would be if you had code that allows downloading files from a particular directory and directory traversal could be used to download files outside of it.

The proof of concept included with the claim simply makes a request to the URL /wp-content/plugins/woocommerce/templates/emails/plain/. If you were to take a look at the latest version of WooCommerce you would see that in that directory there is no index file that would be served when requesting that, so there couldn’t be any code running for there to be directory traversal. There isn’t anything in the proof of concept code that shows an attempt to do anything related to directory traversal either.

What looks to be going on here is that the person behind this thinks that seeing a list of the files in the directory, if a server is configured to do that when there isn’t an index file, would be a vulnerability here. On the same vulnerability database we saw their claim of a directory traversal vulnerability they had submitted a Google dork for “intext:/wp-content/plugins/woocommerce/templates/emails/plain/” and wrote:

When you dork with this,it will generate juciy information in parent directory , for best practice filter according to the country .

That isn’t true though. You should already know what the files that are that directory since the directory shouldn’t contain files that don’t come with the plugin (custom template files would be located in theme being used not in the plugins directory structure).

Somehow, despite the issue being claimed here not actually being a vulnerability on in its own, this has been assigned a CVE number.

01 Dec

Not Really a WordPress Plugin Vulnerability – Week of December 1, 2017

In reviewing reports of vulnerabilities in WordPress plugins we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we have been releasing posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular are items that are not outright false, just the issue is probably more accurately described as a bug. We have been thinking that providing information on why those are not included in our service’s data could be useful, so we are trying out putting a weekly post when that occurs detailing those issues.

Cross-Site Scripting (XSS) Vulnerability in amtyThumb and amtyThumb posts

The claim of a cross-site scripting (XSS) vulnerability in amtyThumb posts is a bit confusing as it is stated that

amtyThumb posts Plugin is prone to a stored cross-site scripting vulnerability because it fails to sufficiently sanitize user-supplied data.

and

The XSS reflected because the values are not filter correctly:

So they are claiming it is a stored (or as we refer to that type of vulnerability, persistent) XSS, a reflected, or maybe both.

The proof of concept given is:

/wordpress/wp-content/plugins/amty-thumb-recent-post/amtyThumbPostsAdminPg.php?”><script>alert(“XSS”)</script>=1

Looking at the underlying code in the file /amty-thumb-recent-post/amtyThumbPostsAdminPg.php it looks like what they are claiming is the vulnerability are in two instances of the following code:

echo str_replace( '%7E', '~', $_SERVER['REQUEST_URI']);

That could would output the variable $_SERVER[‘REQUEST_URI’] without escaping it, which theoretically could lead to reflected cross-site scripting (XSS). But, as we wrote in another of these series of post, that wouldn’t normally be an issue:

The claim that $_SERVER[‘REQUEST_URI’] is unescaped is partially true. While there isn’t any escaping of that done by PHP or WordPress, the value would normally be encoded due to URLs being encoded when sent from web browsers. That would act as escaping. That would normally mean that reflected cross-site scripting (XSS) could not occur due to this issue.

So there doesn’t appear to be the vulnerability as claimed, though there is a reflected XSS elsewhere in the code that we are in the process of trying to notifying the developer of.

After we wrote up the above details, we ran across a related claim of the vulnerability in the plugin plugin amtyThumb, which confirmed our analysis of what was claimed to be an issue in the other plugin. That issue has been given a CVE, despite really not existing either.

10 Nov

Not Really a WordPress Plugin Vulnerability – Week of November 10, 2017

In reviewing reports of vulnerabilities in WordPress plugins we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we have been releasing posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular are items that are not outright false, just the issue is probably more accurately described as a bug. We have been thinking that providing information on why those are not included in our service’s data could be useful, so we are trying out putting a weekly post when that occurs detailing those issues.

SQL Injection Vulnerability in Simple Events Calendar

With a claimed SQL injection vulnerability in the plugin Simple Events Calendar the claim seems shaky before even getting in to the details as it is stated that “Type user acces: administrator user.” If a vulnerability has to be exploited by an Administrator it likely isn’t a vulnerability, since those users normally have the ability to do almost anything (including editing a plugin to remove security code or adding another plugin that can take the action that could be done through the vulnerability).

Where there still could be an issue is with cross-site request forgery (CSRF), which causes a user to take an action they didn’t intend to. The plugin doesn’t include protection against CSRF before the claimed vulnerable code runs, which ends up being part of a real vulnerability we saw while reviewing this claimed vulnerability (and we will disclose that after the developer has had a chance to fix it). With the type of SQL query in claimed vulnerable code that could mean there is a vulnerability if the value of a GET input is involved (which is something we really should have put up a post on by now), but in this case the value involved is from a POST input:

312
313
$edit_event = $_POST['event_id'];
$update = $wpdb->get_results(" SELECT * FROM $table_name WHERE id = $edit_event ", "ARRAY_A");

Since an attacker can’t get back the result of the query in through CSRF in this situation, there isn’t a vulnerability there. While there isn’t a vulnerability, the code could be improved by using a prepared statement and validating the input (since it should only be an integer).

The person behind the claim stated that “Vendor no finded”. We are not sure what that means as the developer’s website is listed both on the plugin’s page on the Plugin Directory and in a couple of place in the WordPress admin area when the plugin is installed. We have notified the developer of the disclosure and the possible improvements.

03 Nov

Not Really a WordPress Plugin Vulnerability – Week of November 3, 2017

In reviewing reports of vulnerabilities in WordPress plugins we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we have been releasing posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular are items that are not outright false, just the issue is probably more accurately described as a bug. We have been thinking that providing information on why those are not included in our service’s data could be useful, so we are trying out putting a weekly post when that occurs detailing those issues.

Full Path Disclosure in Inline Image Upload for BBPress

At the end of September we mentioned that the website WPCampus wasn’t properly crediting us when discussing things we had written, but it isn’t just us that is true with us. Last week in their post on plugin vulnerabilities they credited Wordfence for discovering a vulnerability, but for the other claimed issue they discussed they left out any mention of the discoverer:

For this week’s unfixed vulnerabilities, the Full Path Disclosure issue with the Inline Image Upload for BBPress (and it’s Pro version) isn’t a vulnerability by itself, but can be used in combination with other attacks that require knowing the server path. Hopefully the vendor will release a fix soon, but if not, you can mitigate this issue by ensuring display_errors is disabled for php for your site.  The specifics of how you disable it will depend on your hosting set up.  If you’re not sure, contact your hosting provider or system administrator.

In looking at the linked spreadsheet with the details, we immediately noticed it looked like this wasn’t really a vulnerability as it said in the note for it, “Ensure error_reporting/display_errors is turned off/disabled”. As we noted back in May with a claim made by Wordfence if you consider this a vulnerability then WordPress is also vulnerable:

So is that a vulnerability? We would say probably not if it doesn’t display when error reporting isn’t enabled (though the issue in this plugin could easily be fixed), but if it is, there is a much larger issue because the same thing will occur in the core WordPress software. For example, if you were to visit /wp-includes/wp-diff.php with error reporting enabled you would get this:

Warning: require(ABSPATHWPINC/Text/Diff.php): failed to open stream: No such file or directory in [redacted]/public_html/pluginvulnerabilities.com/wp-includes/wp-diff.php on line 13

Fatal error: require(): Failed opening required ‘ABSPATHWPINC/Text/Diff.php’ (include_path=’.:/usr/local/lib/php’) in [redacted]/public_html/pluginvulnerabilities.com/wp-includes/wp-diff.php on line 13

WPCampus isn’t the only source of WordPress plugin vulnerabilities passing along inaccurate information on vulnerabilities that we ran across this week. During our monitoring of the WordPress Support Forum we looked at thread bringing up a claimed vulnerability in the plugin Comment Attachment. The message from the plugin Vulnerable Plugin Checker that uses data from the WPScan Vulnerability Database shown in the thread stated:

Comment Attachment has a known vulnerability that may be affecting this version. Please update this plugin.

Comment Attachment 1.0 – XSS

That isn’t all that helpful to someone trying to figure out what is going on. Looking at the relevant entry in WPScan’s data pointed to the source of the claim. The instructions for exploiting the claimed issue are as follows:

1) Download “Comment Attachment” And Install
2) Go To Sitting Comment Attachment :
Settings > Discussion > Comment Attachment
3) Insert In “Attachment field title” This Code And Save :
“><script>alert(/Arsan/)</script>
4) And Try To See Your Post And Comment; Follow Link :
http://localhost/wp/?p=1

To access that page you have to have the “manage_options” capability. Users with the “manage_options” capability would normally only be Administrators (and if others are given the capability they would normally be able to create Administrators accounts), which would normally have the “unfiltered_html” capability and therefore could do the equivalent of this.

13 Oct

Not Really a WordPress Plugin Vulnerability – Week of October 13, 2017

In reviewing reports of vulnerabilities in WordPress plugins we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we have been releasing posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular are items that are not outright false, just the issue is probably more accurately described as a bug. We have been thinking that providing information on why those are not included in our service’s data could be useful, so we are trying out putting a weekly post when that occurs detailing those issues.

Directory Traversal Vulnerability in WP Smush

There recently was a report of a directory traversal vulnerability in WP Smush. If you believed the developers (who are also the developer of a security plugin) this is a vulnerability, the changelog for version 2.7.6 is:

  • Security: Fixed path traversal vulnerability. Thanks Ricardo Sánchez(@neorichi) for responsible disclosure.

The report provides a link that is supposed to confirm that it is a vulnerability, that link is to this comment in a thread on the WordPress Support Forum:

@neorichi, Just to update you, we’ve a new security release to fix the bug.

Appreciate your efforts to report this responsibly.

Cheers, Umesh

Looking at the proof of concept it seemed like something might be off about this, as it seemed that you might need a nonce to exploit the issue, but the report doesn’t explain whether a valid nonce is needed or not and if so, where it could be found:

http://localhost/wordpress/wp-admin/admin-ajax.php?dir=../../../../../../&multiSelect=true&action=smush_get_directory_list&list_nonce=xxxxxxx

That URL indicates that an AJAX accessible function is being accessed. Looking at version 2.7.5 that function is only accessible to those logged in, which is not noted in the report (that would make this an authenticated vulnerability at least):

43
add_action( 'wp_ajax_smush_get_directory_list', array( $this, 'directory_list' ) );

Looking the function being accessed, directory_list(), which is located in the file /lib/class-wp-smush-dir.php, you can see that before it checks for a valid nonce it checks to make sure the user making the request has the “manage_options” capability:

341
342
343
344
345
346
347
function directory_list() {
	//Check For Permission
	if ( ! current_user_can( 'manage_options' ) || ! is_user_logged_in() ) {
		wp_send_json_error( "Unauthorized" );
	}
	//Verify nonce
	check_ajax_referer( 'smush_get_dir_list', 'list_nonce' );

Users with the “manage_options” capability would normally only be Administrators (and if others are given the capability they would normally be able to create Administrators accounts), which would normally have the ability to view the directory structure with their capabilities, so this isn’t really a vulnerability.

If you are going to claim this is a vulnerability (as the folks at ThreatPress,  WPCampus, and the WPScan Vulnerability Database have) we don’t see how it could be claimed that it is fixed as the change just restricts you to accessing directories within in the WordPress directory:

349
350
351
352
353
354
355
356
357
358
359
//Get the Root path for a main site or subsite
$root = realpath( $this-&gt;get_root_path() );
 
$dir     = isset( $_GET['dir'] ) ? ltrim( $_GET['dir'], '/' ) : null;
$postDir = strlen( $dir ) &gt; 1 ? path_join( $root, $dir ) : $root . $dir;
$postDir = realpath( rawurldecode( $postDir ) );
 
//If the final path doesn't contains the root path, bail out.
if ( !$root || $postDir === false || strpos( $postDir, $root ) !== 0 ) {
	wp_send_json_error( "Unauthorized" );
}

Persistent Cross-Site Scripting (XSS) Vulnerability in Contact Widgets

A frequent source of false claims of vulnerabilities in WordPress plugins is a lack of understanding of the WordPress security model. WordPress has a capability “unfiltered_html” that allows users to do the equivalent of cross-site scripting (XSS), which in simply terms is just the ability to use JavaScript code. A claim of a persistent cross-site scripting (XSS) vulnerability in the plugin Contact Widgets  involved adding JavaScript code to a widget that is part of the plugin. Normally only Administrators are allowed to edit widgets, so the testing likely was done with a user who has the ability to do the equivalent of the vulnerability.

In one of the responses to the claim, one of the developers responded:

Then this is not a bug. We explicitly allow Administrators to do whatever they want in the widget via that unfiltered_html permission, just as core does with the Text widget.

Looking at the code here is what he is talking about (in the file /includes/class-contact.php):

201
'sanitizer'     =&gt; function( $value ) { return current_user_can( 'unfiltered_html' ) ? $value : wp_kses_post( stripslashes( $value ) ); },

Just to further confirm things were working correctly, we gave an Author level user, who doesn’t have the “unfiltered_html” capability, the ability to edit widgets by giving them the “edit_theme_options” and then tried the proof of concept. As expected the malicious input was sanitized and there was not exploitation, so there isn’t a vulnerability here at all.

06 Oct

Not Really a WordPress Plugin Vulnerability – Week of October 6, 2017

In reviewing reports of vulnerabilities in WordPress plugins we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we have been releasing posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular are items that are not outright false, just the issue is probably more accurately described as a bug. We have been thinking that providing information on why those are not included in our service’s data could be useful, so we are trying out putting a weekly post when that occurs detailing those issues.

Reflected Cross-Site Scripting (XSS) Vulnerability in Google Doc Embedder

Earlier today we mentioned that there are a number of issues with the Plugin Directory’s reviewing plugins before they return to the directory, which is one of many issues that seems like it could be improved if the people behind that were more open about what they are doing and able incorporate outside suggestions for improvement. Another area that seems like it might be improvable based on what is describe below, is deciding when to remove plugins.

The plugin Google Doc Embedder was recently removed from the Plugin Directory and the maintainer of the plugin wrote this about why that occurred:

There was a security alert whereby it appeared a cross-site scripting attack could have been carried out. This was inside a file that was no longer in use so it has just been removed from a new version 2.6.3 that should be released shortly.

Looking at the changes made to the plugin the file referred there was /js/tb-newwin.php. If you were to just look quickly at the code there is what appear to be a reflected cross-site scripting (XSS) vulnerability in it.

First the value of a couple of GET inputs are set to variables without being sanitized:

16
17
18
19
if ( isset( $_GET['url'] ) ) {
	$url = $_GET['url'];
	if ( isset( $_GET['hl'] ) ) {
		$lang = $_GET['hl'];

And then those variable are output without being escaped:

96
thisIFrame = "https://docs.google.com/viewer?url=" + "<!--?php echo $url; ?-->*chrome=true&hl=<!--?php echo $lang; ?-->";

If you were to test out exploiting this, which seems to be a step that is too often not done when checking on possible vulnerabilities, you would find that it doesn’t work. The reason for that is that the file set the content-type to “text/javascript”:

27
header("Content-type: text/javascript");

That would prevent JavaScript code from running. If a web browser could be tricked into believing that the page being served was actually a different content type than what is specified JavaScript code could run. That seems to have been more of a possibility with some older versions of web browsers. Since the page would contain a fair amount of content other than what comes from the reflected cross-site scripting (XSS), it might not be possible in that situation. So while it was good to resolve this, it seems questionable to have removed the plugin for it.

22 Sep

Not Really a WordPress Plugin Vulnerability – Week of September 22, 2017

In reviewing reports of vulnerabilities in WordPress plugins we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we have been releasing posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular are items that are not outright false, just the issue is probably more accurately described as a bug. We have been thinking that providing information on why those are not included in our service’s data could be useful, so we are trying out putting a weekly post when that occurs detailing those issues.

Reflected Cross-Site Scripting (XSS) Vulnerability in Shibboleth

The claimed reflected cross-site scripting (XSS) vulnerability that had been in the plugin Shibboleth is good example of why the lack of testing done for claimed security issues can lead to missing important limitations surrounding them. We first came across the claimed vulnerability when the WPScan Vulnerability Database added the claimed vulnerability, which they didn’t verify before adding to their data set. They cited two references, one being a security improvement change made to the plugin in March of 2016 and the other a discussion on the Debian mailing list. That discussion makes mention of waiting for “real world testing”, but there is no mention of it being completed.

When we did just that type testing before adding this vulnerability to our data set we found that reflected cross-site scripting (XSS) wouldn’t occur. In looking at the underlying claims behind the claim of a vulnerability in this plugin, we found that both the WordPress team and the security company Sucuri (which is part of GoDaddy) had failed to note important limitation with the potential security issue at issue here. Sucuri’s posting about the underlying issue is missing even basic technical details, which if included, might have allowed someone point out that they were overstating the issue (they have a history of doing that sort of thing and worse).

WordPress’ posting on this is better as it provides an important detail which gets to the limitation:

Both add_query_arg() and remove_query_arg() have an optional argument to define the base query string to use. If this argument is undefined, it will use $_SERVER['REQUEST_URI'], which is unescaped. When printed out to a page, this could be used as an XSS attack vector.

The claim that $_SERVER[‘REQUEST_URI’] is unescaped is partially true. While there isn’t any escaping of that done by PHP or WordPress, the value would normally be encoded due to URLs being encoded when sent from web browsers. That would act as escaping. That would normally mean that reflected cross-site scripting (XSS) could not occur due to this issue.

The change made to plugin makes sense since it makes sure the issue couldn’t be a problem and doing that change in general when using the add_query_arg() and remove_query_arg() make sense since when the result of them is used in a different way than this plugin did, it could cause an exploitable vulnerability.

01 Sep

Not Really a WordPress Plugin Vulnerability – Week of September 1, 2017

In reviewing reports of vulnerabilities in WordPress plugins we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we have been releasing posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular are items that are not outright false, just the issue is probably more accurately described as a bug. We have been thinking that providing information on why those are not included in our service’s data could be useful, so we are trying out putting a weekly post when that occurs detailing those issues.

SQL Injection Vulnerability in Photo Gallery by WD

In the report for a claimed SQL injection vulnerability in Photo Gallery by WD it is stated that access to the vulnerability is limited:

Additional: function bwg_edit_tag() has a checking about user permission, so administrator permission is required to trigger this vulnerability.

Checking the code, it specifically requires the “manage_options” capability, which normally only Administrators have and if others had the capability they normally would be able to create Administrator accounts using what that capability provides:

208
209
210
function bwg_edit_tag() {
  if (function_exists('current_user_can')) {
    if (!current_user_can('manage_options')) {

On its own this really isn’t a vulnerability since among other things, Administrators could normally remove any security protection in a plugin. With the information provided it sounded possible that the vulnerability might be exploitable through cross-site request forgery (CSRF), which can cause someone to take an action they didn’t intend to. Though looking several lines further in to the function bwg_edit_tag() shows that there is in fact a check to prevent that from occurring:

218
219
220
  if (!WDWLibrary::verify_nonce('')) {
    die('Sorry, your nonce did not verify.');
  }

Worth noting is that while many fixes for real vulnerabilities don’t get mentioned in changelog the change made related to this was, “Fixed: Security issue”. The change made was to use a prepared statement for SQL statement, which would have fixed this if there really was a vulnerability and doesn’t hurt to have done anyway.