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:

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.

please_upgrade_your_please_upgrade_pageIf you have visited lately using Internet Explorer 7, you would probably see the “It’s time to upgrade your browser” nag, which explains that IE7 and IE6 no longer supported and blocks you from browsing their site until you upgrade.

This is a great step, as even with XP support going away, Vista shipped with Internet Explorer 7, so it will not be dead for some time. When they first started doing this on the Windows site, I thought it was cool that they were finally doing something to clean up the mess they created with their fragmented browser ecosystem.

However, Internet Explorer 8 is still a pretty bad browser…certainly better than IE7, but that isn’t saying much.

If you are going to break your website to force an upgrade, it would be great to use that as a platform to get them into the latest version of Internet Explorer that you can. So, if they are on Vista, go ahead and tell them to upgrade to IE9. Better yet, go ahead and add an optional tool they can use to verify automatic updates is on and set to update automatically, as if they are running IE7, they may not be getting security updates either. And, if they are on IE8, go ahead and add a nag for that too! Although, I think that one may be trickier, as in a in corporate environments, upgrading past Internet Explorer 8 may not be possible. So, rather then fully breaking the site, probably a nice warning would suffice. Be a nice kick in the butt for companies that haven’t upgraded yet as well.

This seems like the right thing to do, especially as dropping support for IE8 has already begun on a number of popular websites. Even Microsoft’s Office 365 has recently announced they are no longer supporting IE8.

I recently had a computer repair for someone who needed me to downgrade Windows 8 to Windows 7, because Windows 8 was not compatible with their work software. For anyone that hasn’t done it, UFI can make this process a bit tricky, as access to the Bios can be limited and booting to removable media troublesome.

When I returned to their house, I did the basic setup and familiarization with them, to make sure they were comfortable with how everything worked, discuss anti-virus, some of the tools I pre-install when I do a Windows re-installation.

They wanted to run their work software while I was still there and I got a pleasant surprise when they booted up an Ubuntu based Live CD.

The company they work for is through Arise, which offers virtual call centers. They were in the process of training to work with Sprint, so I am not 100% sure how the process is after training. However, since they are training on a Linux Live environment, I would be surprised if they didn’t use that for actual work as well.

I didn’t do anything aside from making sure it would boot, but it looked like a very minimal Gnome Install, possibly Gnome 2 or at least classic shell. There were only icons for Firefox, a calculator, and an icon for some minimal settings. It utlized a bootable USB alongside a CD.

I thought this was really cool and a great idea. Linux runs great on most hardware and you can get awesome performance out of older hardware, where Windows would be slow once you started doing any real work.

Using a Live CD is also much more secure, like using a Live CD for your banking, as every-time you restart, it should be to a known-good operating system and programs. I would imagine this also gives the company a lot more control and monitoring capabilities, which they wouldn’t have if they let people run their personal computers. Since so many people’s personal computers have some form of Spyware or Malware, I see this as a no-brainer for companies that have these sorts of remote operations.

Not all companies do this though, I have worked on the computer of someone who worked for American Airlines before. He had worked for American for a while as a call center rep and took the opportunity to work from home when they offered it to him a few years ago. As far as I could tell, there wasn’t any sort of required anti-virus and very little over-site to what was running on the person’s computer, aside from running American’s call center software. Pretty scary when you think about how often their call center reps probably deal with credit card information and other confidential email during the day.

While viewing Softlayer’s Website today, I noticed something rather amusing…they are using Amazon’s Cloudfront to deliver at least one script on their homepage.

Softlayer is a hosting company, which does a lot of dedicated hosting. However, especially since being acquired by IBM, they have been heavily promoting the cloud side of their business. So, it is sort of funny that they are using their biggest competitors service on the homepage of their website to serve up javascript, rather then their own Cloudlayer or other infrastructure.

Of course, you should use what works, works well, and is easy, which in many cases is an offering by Amazon AWS. However, if your goal is to ‘to Accelerate Adoption of Cloud Computing in the Enterprise,’ you should probably keep your hosting in-house as much as possible and not showcase the reliability and reach of your competitor.

As an aside, this reminds of a similar situation a few years ago when Dreamhost was having some major downtime. I noticed that the Dreamhost status blog was always up, despite probably getting crazy traffic from all of their customers, while their shared hosting hosting infrastructure was seeming to crumble. I checked and saw they were using Linode to power their status blog, still do. That ended up being a good recommendation, as I switched to Linode shortly after that and have been overall happy with them ;)


See bottom of post, for the TLDR problem/solution:

I have been using XFCE for some time now and overall really enjoy it. I switched to XFCE after giving Gnome 3 a go when it first came out and have been using it since. It has gotten a lot better since then too.

For instance immediately after switching, one of the only things I missed from Gnome2 was tabbed file browsing. Thunar, the default file manager for XFCE, got that awhile ago and has generally been improving a lot.

Another change to XFCE is the way it remembers your desktop settings, windows, and programs when you logout. I admittedly have not researched this as much as I should, but anecdotally I noticed some changes to how this works when I upgraded to a newer version of XFCE recently. I also noticed that there seems to have been a change with the way that XFCE deals with multiple monitors, as after upgrading certain programs starting using the entire width of two monitors when initially drawing their windows, rather then using a single monitor as they had in the past.

Onto the problem: After getting new monitor that supported a higher resolution(1920×1080) and updating my xorg.conf, my resolution would get reset to my old resolution(1680×1050) as soon as I logged back in to XFCE.

I use Nvidia drivers, as I have found them to offer a bit better performance and support for a multi-monitor setup, not to mention generally quite easy to configure. Its been awhile since I tried using it, but the built-in display manager for XFCE has not been well suited to using multiple monitors in the past, while using nvidia-settings provides a nice easy to use GUI for arranging and setting up displays.

I tried several different things with my xorg.conf and nvidia-settings, including removing it all together, as well as a variety of different configurations. However, no matter what I had in my xorg.conf, as soon as I logged in the resolution was reset to the old resolution. It seemed like XFCE was ignoring my xorg.conf settings or overriding them.

I was fairly confident that the xorg.conf was correct, so I began looking elsewhere. I grepped my ~/.config folder for my old resolution and did in fact find it listed the old resolution in: xfce4/xfconf/xfce-perchannel-xml/displays.xml.

I tried changing it there to the new resolution, however it still reverted back to the old one. Finally, after being a bit fed up and fairly confident that the saved settings/sessions were to blame, I moved my config folder to a backup: mv ~/.config ~/.config_back

This unfortunately has the side effect of clearing all(or most) of your saved XFCE settings, but as soon as I did that, it started using the new resolution. I have in the past done some messing with xrandr settings in order to get multi-monitors working better, so it is possible this is my own doing, but there was definitely some xfce setting in my config that was reverting the resolution.

This is something that I should learn more about and rtfm a bit, but sometimes killing it with fire works and is the easiest/quickest solution…


Problem: After getting a new monitor, the resolution specified in Xorg.conf was ignored when logging in to XFCE. Instead, each time I logged in, it reverted to the old resolution.

Bad Solution: This is probably not the best way to address the problem. However, moving ~/.config to ~/.config_back cleared out whatever xfce setting was over-riding my xorg.conf and let me use the new resolution.

Caution: Again, this isn’t a good solution, but it worked. If you do the above, it WILL delete all of your XFCE settings, like panels! A better solution would be to learn why/where that setting that maintains old resolution is kept and changing it!


Get every new post delivered to your Inbox.

Join 46 other followers