With the start of IE9, browser testing got a whole lot easier. While it still has some annoying warts and limitations, it is way better than IE8 was and doesn’t even compare to the nightmare that was IE6 and before. Now with IE11+, Microsoft has stepped up their game and is more in-line with browsers like Firefox and Webkit Browsers(Chrome/Safari/Etc.)

Back a few years ago, dropping support for IE 8 gained steam, despite the fact that for people still using XP, IE8 was the latest version of Internet Explorer you could get. Google may have been the forerunner on this, as they dropped IE8 support in 2012 for their Apps, but other companies/devs were already limiting support by then as well. Since then, both due to dwindling numbers and better alternatives, many new devs don’t even test it anymore and the web simply don’t work well for those running it.

Apparently, Microsoft Devs don’t either.

While preforming a clean install of Windows 7, I decided to checkout a few pages in it and came across the Windows 10 page. The below screenshots are from the new Windows 10 Upgrade Page and as you can see, it wasn’t cross browser tested in IE8.


After turning on Compatibility Mode, I got the below. It actually worked better, although I got a script error that slowed the browser to a crawl.

IE 8 After Turning on Compatability Mode

Just to be on the safe side, I fired up my IE8 XP Virtual Machine, which has all the XP Internet Explorer Updates, as to be fair the windows 7 machine hadn’t had any updates yet. As you can see, it looks similar, just with certificate errors.

ie 8 xp

So, it seems that Microsoft doesn’t care too much about cross browser testing in Internet Explorer 8 anymore, which I suppose is good as it is another nail in the coffin. Of course, I can’t help but think that given they are the ones that spawned this demon on us, the least they could do is continue putting some man hours towards it.

Personally, while I don’t spend time making sure everything looks identical in IE8, I do at least check it and typically make the page largely readable. Does it matter? Probably not, as if you are still running Internet Explorer 8, the web is probably a horribly broken place, but basic IE8 support is something I include in most cases.


While visiting Google Maps I saw what is(at least to me) a new noscript warning. A screenshot of it is below, the message is:

When you have eliminated the JavaScript, whatever remains must be an empty page.

I got a kick out of somewhat proverbial warning. Sure beats the common “we have detected that javascript is disabled in your browser” warning that is so often used. They even came up with a graphic for it, which thanks to a commenter below, is because this is apparently play on a Sherlock Holmes quote.

Can’t argue with them about it either on Maps…you need Javascript for that. Now if it were Google groups… ;)

Google Maps no Script

Recently, an old client contacted me because emails were not being sent from their Godaddy hosted wordpress site. A quick look at the folders in their webroot made it clear that the site had been hacked and most likely the emails not working was a side-effect of godaddy noticing and blocking their email function.

After a bit of investigation, it looked like the most likely avenue was from the CherryFramework, which is a bootstrap wordpress theme/plugin framework. A bit more digging and I discovered a recently patched vulnerability in cherry-plugin/admin/import-export/upload.php

The entire contents of the vulnerable file is below:

	if(strtolower($_SERVER['REQUEST_METHOD']) != 'post'){
		exit_status('Error! Wrong HTTP method!');
		$upload_dir = isset($_REQUEST['upload_dir']) ? $_REQUEST['upload_dir'] : $upload_dir ;
		$file_name =basename($_FILES['file']['name']);
		$upload_file = $upload_dir.$file_name;
		$result = move_uploaded_file($_FILES['file']['tmp_name'], $upload_file);

As you can see from the above, which is the first version uploaded to git, the ONLY checking this file does is whether or not you are sending it some files to upload and telling it where to send it. So, it conveniently lets you upload any file to any directory on the webserver. Similarly, their download-content.php file also let you download arbitrary files from the webserver, with 0 checks in place to prevent abuse. You can see a screenshot of the github repository here.

This was fixed in later versions of CherryFramework and shows that the developer better understands wordpress now, as they not only implement a nonce and checks the logged in user’s capabilities by calling current_user_can, but also adds the code to an ajax action rather than just a malware installer like it was before.

Without casting too many stones, as no-one is perfect least of all me, I just can’t understand how something like this could get written, if not intentionally(which is entirely possible.)

Everyone makes mistakes and it is easy to miss something that can be abused…mistakes happen, get fixed, and we move on. But, something like that or SQL queries written with 0 thought to injection blow my mind.

Update: Newer versions of GTK3 do work better, so with the upgrade to Fedora 23, the search file chooser is functional…it just operates differently than the old search. See below ‘GTK Filechooser and Fedora 23’ section at bottom of post.

After updating to Fedora 22, the File Chooser in Firefox XFCE, like you would see when you click ‘Open File’ or upload a file, was broken.

Specifically, while the open file dialog does open and let you select files, the quick find was not working properly. Normally, you can start typing the first letter(s) of a file name and the file browser will jump to files that start with that letter in your current folder. However, this was not working for me in Firefox and instead typing a letter did nothing. Further, the files were not grouped by folders, but rather displayed files/folders together(although this might not be a setting.)

It turns out this isn’t a bug with Firefox, but rather a problem with GTK3’s Filechooser Dialog. A bug is currently open here, so hopefully it will be addressed soon.

In Fedora 22, Firefox is compiled to use GTK3 instead of GTK2, along with Gedit and I would imagine a few other programs. So, anything using GTK3 has this bug for me.

A Temporary Solution: Since this makes using Firefox and selecting files incredibly painful, a quick fix is to uninstall Fedora’s version of Firefox and install Firefox separately(by downloading or compiling.) The version available directly from Mozilla does NOT use GTK3, so works fine. Just make sure to stay on top of updates and keep an eye out for when Fedora updates GTK3, as this will probably get fixed soon.

Hopefully, this will save someone the amount of time I spent trying to figure out why it was broken…

The GTK3 Filechooser, shown on right, does not currently work correctly in Fedora 22.

The GTK3 Filechooser, shown on right, does not currently work correctly in Fedora 22.

GTK Filechooser and Fedora 23

The upgrade to Fedora 23 brought a functional GTK Filechooser, although it operates in a different manner than the older GTK2 version. I like it better in some ways, although not 100%. In terms of searching files, the search works against the entire file name, not just the start of the name. So for instance, if you type test it will pickup the file test.txt as well as file_test.txt. It also sometimes searches sub-folders, which can be a bit of a pain if you have a ton of similar naming files…but it does actually search now…

google switch search engine

While doing a Google search this morning, I noticed an interesting message from Google above the search results. It said, ‘Switch your default search engine to Google.’

Clicking the Learn how button takes you to a page with steps and screenshots showing how to change your default search engine in Firefox.

This is in response to a recent deal between Firefox and Yahoo, where Yahoo replaced Google as Firefox’s default search engine. According to reports the change has provided a small boost to Yahoo’s already rather small percent of the search market, with Google also loosing 1 percent during the same time.

Whether this is due to actual concerns over loosing customers or just not letting their competition have anything easy is anyone’s guess. However, this is not the only time Google has used it’s market position to attack their competition. For years, Google has been pushing Google Chrome on Firefox and Internet Explorer users.

google switch search engine

Update 03/20/2015: The following adblock element hiding rule seems to work to get rid of it: google.com##DIV#taw

After cleaning up a recent WordPress hack, I believe there is another Revolution Slider vulnerability making the rounds. If you are using an old version of Revoltion slider, you should update immediately or disable the plugin.

From what I can tell, it affects two Themepunch plugins, Revslider and Showbiz Pro. According to a proof-of-concept exploit posted this month, versions 3.0.95 and before of Revslider, as well as versions 1.7.1 and before of Showbiz Pro are vulnerable.

The issue allows for unauthenticated ajax calls sent /wp-admin/admin-ajax.php to trigger Revolution Slider’s onAjaxAction function, which in turn can be used to delete slides, import/export slides, and update the plugin(among other tasks.) In the case of the site I cleaned up, they used it to trigger an update to the plugin, which uploaded a remote shell to the site.

From looking around, this vulnerability appears to have been posted relatively recently on several sites and is currently being exploited.

The Vulnerability

This is part of revslider_admin.php. In affected versions, the below gets called, which adds wp_ajax and wp_ajax_nopriv callbacks for the onAjaxAction function.

Since there is no check on whether the user is actually logged in or allowed to make changes to the plugin, it is possible to(among other things) upload files to the server.


self::addActionAjax("ajax_action", "onAjaxAction");

This in turn calls the addActionAjax function, which creates the wp_ajax and wp_ajax_nopriv callbacks.


protected static function addActionAjax($ajaxAction,$eventFunction){
	self::addAction('wp_ajax_'.self::$dir_plugin."_".$ajaxAction, $eventFunction);
	self::addAction('wp_ajax_nopriv_'.self::$dir_plugin."_".$ajaxAction, $eventFunction);

As a result of this, the revslider_ajax_action action gets added, allowing for unprivileged updates. This is not terribly surprising as, at least in early versions of Revolution Slider, security and a deep understanding of wordpress do not seem to have been a concern.

Working Example

The following is a working example. On a vulnerable site, the following will print an ajax response similar to: {“success”:false,”message”:”wrong ajax action: asdf “}.

If you see something to the effect of {“success”:false,”message”:”Wrong request”}, you are probably not vulnerable, but should still verify you are running the most recent version, as there are several known vulnerabilities at this point!

<form method='post' action='/wp-admin/admin-ajax.php'>
<input type='hidden' name='data' value='asdf' />
<input type='hidden' name='client_action' value='asdf' />
<input type='hidden' name='action' value='revslider_ajax_action' />
<input type='submit' />

The reason you see this response is because the switch is called and since asdf is not a recognized action, it triggers the default: self::ajaxResponseError(“wrong ajax action: $action “);

Affected Versions

As stated above, this does not appear to impact newer versions 3.0.95 of revolution slider, as well as versions 1.7.1 and below of Showbiz Pro.

In a newer version I checked, Themepunch appears to have added a nonce called revslider_actions and check that the nonce is present in onAjaxAction prior to actually executing the ajax calls.

Temporary Fix

If you are using an old version of revolution slider, you should update immediately and/or disable the plugin.

As stated before, since this plugin is often included with themes and is a premium plugin, updating it presents several difficulties and is something that a non-tech website owner might not even know they need to do. I feel this leaves something to be desired.

The below should be a quick way to stop the attack.

**Note that the below will only allow people with the privilege to install plugins to work with Revslider’s Ajax calls. You may want to adjust what permission you allow.


public static function onAjaxAction(){

if(!function_exists('current_user_can') || !current_user_can('install_plugins')){

Given that there have been two very serious vulnerabilities reported in the past few months, I would strongly encourage you to upgrade the plugin to the latest version and/or use a different plugin!

Yesterday, a vulnerability in an old version of Revolution Slider was reported. The vulnerability allows visitors to view arbitrary files on the web server, like wp-config.php, without being logged in. All you need to view any file on the server is to know the location of the file and for the web-server user to have permission to view it.

According to ThemePunch, the plugin developer, the vulnerability was patched 29 versions ago in February, but they decided not to publicize the severity of the issue, aside from a single ‘fixed security issue’ line in their change log. This was because:

“[We were] told not to make the exploit public by several security companies so that the instructions of how to hack the slider will not appear on the web.”

As a result of this negligence and the way that Revolution Slider is Updated and bundled with themes, this simply left any website not running a recent version of Revolution Slider vulnerable for months to an extremely serious file inclusion vulnerability.

Its Your Fault For Not Updating

This seems to be the company line for this issue. After the vulnerability was made public, they have stated:

“You should always keep the slider up to date like any other WordPress component but urgently need to do this when using Version 4.1.4 or below in order to fix the security issue. […] We are sorry for you guys out there whose slider came bundled with a theme and the theme author did not update the slider. Since you cannot use the included autoupdate function please contact your theme author and inform him about his failure!”

And it is true, you should keep your plugins updated.

However, this is a paid plugin and doesn’t allow easy updates like a normal wordpress plugin does. Further, on all of the sites I fixed, they didn’t appear to have a nag telling the user an update was available from the backend. So, unless you are a developer and actively visited the plugin’s website, you wouldn’t even know the plugin needs to be updated, let alone an extremely serious security vulnerability.

As they mention, they sell a developer license that allows developers to include the plugin in their theme. When the plugin is included with themes, you can’t update it without updating the theme. So, any theme that isn’t regularly updated is at risk. And, since some shoddy developers edit the theme directly, rather than making a proper child theme, it isn’t always easy to update the theme. This, of course, isn’t the fault of ThemePunch, nor is it good practices to develop like this, but it does happen and is going to be a legitimate problem for people.

Even if you actually have the premium plugin itself, you can’t just update it. There is no auto-update feature(at least not in the vulnerable versions I saw,) so you can’t update it like you would a regular WordPress plugin. Nor, to my knowledge, is there an update nag on the plugin page telling users they need to update. Instead, you need to download the premium plugin, which requires a login to the site that sells it. 

The catch here is that most website owners aren’t going to have access to the login information needed to update the plugin. Your average website owner isn’t a developer. They probably paid someone to create the theme, who presumably installed a valid copy of the plugin. Unfortunately due to the nature of web design, this simply means that hundreds(thousands?) of sites are silently vulnerable to an extremely serious vulnerability and won’t even know it, unless they have a responsible web developer or host. Again, this isn’t the fault of ThemePunch, but is a fault with the premium plugin model when it doesn’t allow for quick/easy updates.

Negligence Through Security Through Obscurity

According to the plugin author, this vulnerability was fixed in February, but they chose not to report it. It has been reported that this vulnerability was publicly disclosed months ago and regardless, it is safe to say that it was known by some people for the past few months.

By choosing not to report the vulnerability and making site owners aware of this huge security risk, they effectively pushed back the date where we found out about it leaving their customer’s sites vulnerable to a known attack. And, now that is is released and being exploited like mad, we are left scrambling to fix it anyway. So, not reporting it only helped the bad guys.

I understand fully that this is a paid plugin and the need for them to protect it. I get that. And, I understand that you should keep your plugins updated. Nothing in their statements that I have seen is untrue.

However, in the event of a serious vulnerability like this, not making a valid attempt at reporting it, especially when you know that your plugin doesn’t get updated frequently and the vulnerability likely impacts a large number of sites, is negligent.

Updating a Plugin You Can’t Update

I don’t use this plugin on WordPress templates I develop, but it is used by several clients that I host. I found it bundled in two client’s themes and installed as a plugin for two other clients. All 4 had their wp-config.php file downloaded already and all sites on my servers have been scanned for this vulnerability already.

I wrote a quick and dirty patch for the outputImage function, which you can view here. This is only meant as a temporary fix, until you can assess the issue and do a proper update, but since this attack is ongoing and widespread, you should take some sort of action asap.

Mod_Security also appears to block the attack.