Serious Bug Discovered In The All In One WordPress Security and Firewall Plugin

All In One WordPress Security and Firewall Featured Image

Pippin Willamson, creator of the AffliateWP plugin, has discovered a serious bug within the All In One WordPress Security and Firewall plugin. According to a forum thread created by Williamson, All In One WordPress Security and Firewall automatically detects option ids with fwp as malicious and deletes them.

Known WP Pharma Hack Entry: fwp and option_id: 1101143
The options table entry with known pharma hack for option_id 1101143 with option_name affwp_settings was successfully deleted

The pharma hack was well underway in early 2011 but made headlines in the WordPress community when Chris Pearson, published a detailed guide explaining how to detect and remove the malicious code. Even though fwp is an option id commonly used by the pharma hack, it’s used by legitimate WordPress plugins as well. As Williamson explains, blindly checking for and deleting fwp in the options table is dangerous.

While it is true that sites that have been compromised by the pharma attack do often contain option names with fwp, this is in no way a conclusive test.

Blindly assuming that an option matching fwp is malicious is really pretty poor and not friendly to legitimate settings that are stored in the database that contain any version of fwp.

For example, all of our settings are stored with a prefix of affwp_. That means that every single one of our database options are immediately flagged by your plugin and deleted without question or any additional evidence to support the malicious flag.

The sheer number of plugins that could be negatively impacted by this poor attempt at accurately identifying malicious option rows is staggering. wp is used in a huge number of plugins and is often combined with a letter or word that represents the plugin, so it’s highly likely that other plugins store options that include the letters fwp in their option name.

Although I don’t use AffliateWP, I installed WordPress All In One Security and Firewall on my localhost and used the database scanner to see if any option ids are discovered using fwp. During the database scan, it discovered the option id of sfwpavatar and promptly removed it from the database. Sfwpavatar is related to the Simple Forums plugin, specifically to handle avatar images. The id has nothing to do with the pharma hack.

All In One Security Database Scan
FWP Detected!

Option 150 as seen in the wp_options table in the database.

This Is The Option Discovered by All In One WordPress Security and Firewall
This Is The Option Discovered by All In One WordPress Security and Firewall

I reached out to the developers of the All In One WordPress Security and Firewall plugin to find out when a fix can be expected. At the time of publishing, they have yet to respond. This post will be updated when or if they respond.

Until an update is pushed out that explicitly addresses this bug, I would avoid using it or at the very least, the Database Scanner.

New Version Temporarily Disables Database Scanner

The team has pushed out a new version that addresses the issue discussed in the post. You should already see an update notification in the dashboard. According to the change log, the update temporarily disables the Database Scanner.

18 Comments


  1. Pippin posted that 19 hours ago. Can’t we wait a little bit more until the plugin authors have time to properly respond to that before we make this another public “shame on you” thing? Good lord, what we have become…

    Report


    1. No. The plugin has 5 maintainers and no one has responded to the support thread started by Pippin. 19 hours is more than enough time to at least confirm and give out a public statement which of course, I would have happily linked to and quoted. It’s also not a security flaw as some may have implied from the title (my apologies) so I’m not putting any sites at risk.

      I also provided them ample time to respond to my email inquiry. This is not a shame on you type of post, it’s to inform its users that data loss can occur under the right conditions.

      Report


      1. Dear Jeff,

        Just for the record…

        1.The plugin doesn’t have 5 maintainers. When you see a plugin with many authors, not necessarily means that all of them have the same implication and/or responsabilities.
        2. As you probably know WP.org repositories allows only commits from the user who submitted the plugin at first place (the owner). So it depends always on one person only to submit fixes.
        3. Only that “owner” of the plugin receives notifications when a support thread for his plugin is created.
        4. Not all people are in your timezone. 19 hours in your timezone can be much less working hours in the plugin’s author country depending on the time difference due to different timezone.
        5. I’m in the author list and I didn’t receive any message from you about this (no email, no tweet, nothing…).

        Apart from this. I think this post, and especially the title, is too far from being honest.

        Serious bug? really?

        It was affecting only to users who uses a certain feature, that requires the user to run it manually, and only in a particular scenario (with AffilliateWP installed or any other plugin with ‘afw’ in the options_name).

        After more than 350.000 downloads, this was the first report of this bug (that was there for long time). So I honestly think that it was not too serious if after more than 350.000 downloads no one had the issue until now…

        By the way, I have both plugins installed and never had the problem.

        Best regards.

        Report


      2. I was under the impression that each author listed had commit access. Thank you for the clarifications.

        Anytime data loss occurs and in this case, can happen without the user even realizing it is a serious issue to me. You’re correct in that this issue only affects those in certain situations using a specific feature, but it happens none the less. A user decides to do a database scan and the next thing you know, option IDs disappear. That is not cool, is a serious problem, and I’m happy to see a new version that fixes the problem.

        You mean “fwp” in the options name as you can see from the screenshots in the post.

        After more than 350.000 downloads, this was the first report of this bug (that was there for long time). So I honestly think that it was not too serious if after more than 350.000 downloads no one had the issue until now…

        Guess we’ll never know how many option ids were deleted without the user’s consent. I stand by my claim that it was a serious bug even if this is the first time it’s been reported to cause an issue.

        The one point I agree with is that using the word flaw and security in the post title lead people to think it was a serious security vulnerability. I immediately changed the title and wording to reflect that it was not. Lessons learned for the future.

        Report


      3. I’m not taking sides here, but I want to clarify that your statement #2 about “only the plugin owner having the commit access” is false.

        A plugin owner / admin can give other users commit access by clicking on the Green Admin button that only the plugin owner sees.

        Also it’s important to note that Authors / Committers are completely separate in the way they’re handled.

        List of Plugin Authors are controlled via the Readme file in the plugin. The committers list is maintained by plugin owner on wordpress.org site for that individual plugin.

        Simply add /admin/ to the end of the plugin URL, and you will see the admin page.

        Also clarification on #3 — each plugin has a support forums RSS tag that you can use to be notified if you have multiple support staff members.

        Report


  2. Rafael, the wait time you’re referring to is typically meant for vulnerabilities/backdoors etc. Posting this ASAP is actually a benefit for the user since it will hopefully prevent a user from deleting an option before the plugin is fixed. As opposed to waiting to publicly talk abut a plugin that has a back door or vulnerability that someone could exploit. Very difference scenarios.

    Report


  3. Jeff,

    Wasn’t another situation that someone found an exploit, you said she should of waited at least 24 hours before disclosure? yet you only waited 19 hours.

    Report


    1. This is not a security vulnerability situation. It’s a serious software bug that can lead to data loss.

      Report


  4. Hi,
    As Jeff Chandler already stated in his last comment, the current behaviour of this feature, particularly as it applies to “fwp” option name isn’t a security hole. However the feature does need some improvements in the way it handles false positives.

    We will make those improvements and re-introduce that feature soon.

    Currently we are in the process of releasing an updated version of the AIOWPS plugin today. In that release we are going to temporarily deactivate that feature until we introduce our improvements.

    Thanks,
    Peter
    AIOWPS plugin author

    Report


    1. I am glad to see that ya’ll are active on updating the plugin. I haven’t ever looked at AIOWPS but will be now for sure.

      How does it affect performance?

      Report


  5. Bringing such conflicts to the attention of the WP community is great. Kudos.

    Using a title that implies a serious issue in a security tool is alarmist.

    Some perspective …..

    1) ~360K downloads of AIOWPS

    2) Of these, only a fraction will be active. Let’s be generous as 25%.

    (Peter if you have the numbers that would be great)

    3) Of the ~90K active AIOWPS installations, only a few will have plugins that conflict.

    Lets be generous again at 25%.

    4) Of the ~22K AIOWPS installs with conflicts, maybe half run the tool.

    So that’s 11,000 out of 75,000,000.

    Let’s say I a off by 10X.

    The issue impacts Just 0.14% of sites.

    Report


    1. I learned a few things from the original title I used, especially with using the word flaw and security in the same title. Anywho, as I explained in another comment, any data loss to me is a serious issue. I really don’t like how you and others are using all these number and stats to downplay the issue of data loss, whether it’s critical or not. If I come across or someone reports a plugin that allows users to lose their data without their consent, I’ll use the same verbiage and language because it’s unacceptable. I mean, it almost sounds like you’re ok with just 0.14% of sites being impacted.

      As a user, I place trust and confidence into security tools like All In One Security and Firewall to protect my site. I understand what the scanners do but I definitely don’t understand the things it detects. In this case, I’m aware of what the pharma hack means and I’ll take what the scanner is doing as expected behavior. I trust that it’s doing its job without any negative side effects. As it turns out, that wasn’t the case.

      You’ll never truly know how many things were removed from users databases that shouldn’t have been touched.

      Report


  6. I’m not sure why you’re catching so much flak on this, Jeff. Your reporting was accurate, honest, and a service to the WordPress community. I read the original post title and the new one. Neither are incorrect or alarmist. It’s not your responsibility to teach people how to read.

    Also, whether this is currently an issue for one user or 350,000 doesn’t negate the seriousness of the bug in the plugin. This is also the reason I re-tweeted Pippin’s original tweet on this. It is a serious bug.

    Report


  7. @ Jeff Chandler – THANK YOU!!! Finally the answer to a very difficult mystery problem that I have been trying to figure out for quite a while now. I have 2 users that are using the BPS Pro DB Monitor feature and the All in One… plugin has been deleting data and triggering the DB Monitor. I had been looking in the wrong place and after finding this post I have confirmed that the source of the problem is All in One… Thank you again! Yeah mystery solved finally. ;)

    Report


    1. You’re welcome although I pass on your thank you to Pippin who initially reported the bug.

      Report


      1. @Ed,
        I just want to clarify that this is no longer an issue with the latest few versions of the AIOWPS plugin – we’ve temporarily removed the DB scan feature and we are in the process of improving that functionality.
        Regards,
        Peter
        AIOWPS plugin author

        Report

Comments are closed.