Sorry I didn’t do a report for last week. I had the honor of speaking at WordCamp Miami last week so was a bit busy. Speaking of which, if you weren’t there, or were but was at one of the other excellent presentations, they’ve now posted the recorded version (I start at roughly 0:33:00). In addition, my talk from WordCamp St. Louis is now posted over at WordPress.tv. And if you prefer to see it live, I’ll be presenting it again at WordCamp Kansas City on April 29th.
I recently purchased a new computer to replace my 10+ year old machine at home. I’ve been using Hyper-V for virtualization because it was built into Windows 10 and allowed me to immediately use the Virtual Machines I had previously set up with VirtualPC under Windows 7. However, Hyper-V’s features with Linux guest systems is extremely limited and since I use VirtualBox regularly on my Mac at work, figured I’d install it and move my Linux guests over to it.
I started off attempting to set up a Kali Linux VM in VirtualBox. I immediately noticed VirtualBox wasn’t recognizing my system as 64 bit, and wouldn’t let select more than one CPU. I have 12 cores, so I would think I’d be able to assign more than one. Upon the first attempt at booting the VM I ran into a BSOD in Windows 10 (side note: at least the BSOD in Windows 10 is friendlier than in the past). Subsequent attempts at booting the VM all ended with me staring at a BSOD in my host OS.
After a lot of experimentation and googling, you can’t have Hyper-V installed if you want to use VirtualBox on Windows 10. You’ll need to remove Hyper-V completely before you can run a guest OS in VirtualBox. I assumed you could have them both installed, but not run simultaneously. Nope. Hyper-V will need to completely removed before you can VirtualBox. Once I removed Hyper-V, VirtualBox recognized my system as 64bit, and I was able to assign more than one CPU to the guest OS. The VM booted right up. And since I’m not planning on running any Windows VMs, I won’t miss any of the features that Hyper-V offers over VirtualBox.
Now, it’s possible that VMWare Workstation Player can run along side Hyper-V, or at least not cause a BSOD, but it’s also $150.
Occasionally I’ll find myself in a situation where I’ll need to manually change the login name on a user. Normally, this is as simple as changing the user_login and user_nicename in the *_users table. Recently I needed to change the login on an account that was also the Super Admin of a WordPress network (multisite). I assumed that the flag for Super Admin was contained in the *_usermeta table. After logging in to verify the account was working, I discovered the account no longer had access to the Network area, and no longer had access to any plugins.
Turns out the flag to denote a Super Admin is actually stored in the *_sitemeta table with a meta_key value of site_admins as a serialized array. Change the value to the revised login name, making sure to adjust the string length to match the new name. Apply the changes (or run the update query) and log back in with the new login name. Everything should be working as expected again!
You should have already noticed that WordPress released version 4.7.3 update on Monday. 4.7.3 addresses six security vulnerabilities (one of which was discovered by my buddy Delta!) in addition to 39 bug fixes. Equally important is that security patches were issued for all WordPress branches back to version 3.7. If you are running any version of WordPress from 3.7 forward you should update immediately as there are now attacks in the wild targeting the vulnerabilities that were corrected.
If you are on an older version, please strongly consider upgrading to a more current branch. While I applaud the WordPress team for patching all branches back to 3.7, you can’t rely on them supporting those older branches moving forward. Staying up-to-date is one of the most important ways to protect your site. The WordPress development team has done an amazing job of ensuring backwards compatibility, so unless you have made changes to the core WordPress files, there is a strong chance you can update to the latest version without incident. If you’re unsure of updating, please reach out to me and let’s see if we can get you updated.
I had hoped this week’s report would be quieter, but instead includes five unauthenticated arbitrary file upload disclosures. PLEASE, remove or update these plugins immediately.
WordPress update 4.7.3 was released earlier today. 4.7.3 is a maintenance and security update and corrects six security issues. Let’s just hope there aren’t any undisclosed security patches and the 4.7.3 update is much quieter than the 4.7.2 update.
If you don’t follow me on twitter, you might have missed that I’m speaking at both WordCamp St. Louis on March 18th and at WordCamp Miami on March 25th. If you’re going to be at either event, definitely stop me and introduce yourself!
For both events, tickets are limited, so make sure you reserve your spot now!
This week’s report is pretty large, due in large part to the disclosure of the remaining discoveries from last year’s sumofpwn that were never fixed, despite repeated attempts to contact/work with the developers.
There are a couple of items in the report I want to address directly. They are listed in the notes section but I want to highlight them. In looking at the svn repository for Adminer, they fixed the issue in v1.4.5, but the plugin has been removed from the public repository. In general, having a world-accessible direct connection to your database is a bad idea. I would suggest going ahead and removing the plugin if you have it installed. You can read more about the initial disclosure.
The disclosure for FormBuilder was for version was 1.0.5 with the latest version being 1.0.8. Though the initial disclosure doesn’t mention it, the plugin does output the contents of user supplied data in other areas (and continues to do so in the most recent version). In addition, the plugin’s description mentions that the plugin is reaching end of life.
Be advised, FormBuilder is nearing end-of-life and may not be actively maintained in the future. It is advisable to switch your WordPress site to some other Form handling plugin at this time.
Given it continues to have potential issues and it’s reaching end-of-life, I would strongly suggest removing.
In regards to the Trust Form plugin, there is a version in the svn repository (2.0.1) where it appears the author tried to address some of the disclosed vulnerabilities. However, there are other areas that are still vulnerable to cross-site scripting, which is most likely why the plugin has been removed from the public repository. I would strongly suggest removing the plugin.