Mark Maunder
Forum Replies Created
-
Thanks Mick. The release that went out this evening fixes this issue – that’s version 5.2.3 – along with a few other nice improvements like a newer country database.
For someone to exploit this they’d have to hit your site with something that lets them generate a fake referrer. Then get you (while logged in as admin) to go to Wordfence, open live traffic, look at their referrer along with all the others you’re seeing and click it. Alternatively they need to get you to look at live traffic and then click their IP address to see all traffic from their IP – that’s another way to get their XSS to execute.
The fix has been released in version 5.2.3 and if you have auto-update installed you’ll be auto upgraded within 24 hours.
The fix will apply to traffic that has already been logged along with new traffic.
Regards,
Mark.
Hi Simon,
Replied to your emails. Just wanted to add a note that noc3 is running fine and I’m working this issue with Simon via email so marking this resolved.
Regards,
Mark.
Hi Martin,
Tim alerted me to this issue. Please make sure that the user that WordPress is using to access your MySQL has permissions to either truncate or “delete from” the table.
You can go ahead and truncate the table yourself using the mysql command” truncate table wp_wfHoover;”. DO NOT just delete the file or you’ll corrupt your DB. Only do this via mysql.
Then run a scan and let us know if it’s completing and what the status is of that table after the scan.
Thanks.
Hi David,
(I edited this after posting it for clarity – see marked paragraph)
This looks like an issue with your server. Please read the following article on the mysql docs site:
http://dev.mysql.com/doc/refman/5.0/en/innodb-troubleshooting-datadict.html
It looks like your data dictionary is out of sync. Specifically you have a .frm file that exists in your schema for wfHoover but there is no corresponding data dictionary in the InnoDB file. (read the article to understand how mysql maintains two separate dictionaries)
Edit: (adding this for clarity) Please note that we don’t control how frm files are created or deleted or the integrity of the InnoDB and mysql data dictionary so this really can’t be our fault. We just run standard SQL create/delete statements and don’t even force a specific table type – we just use the default. And we’re using InnoDB on our own servers so there’s no known incompatibility there.
So I think there are a few possibilities:
1. You ran out of disk space and an frm file was created but the server could not update the innodb dictionary during update.
2. You have disk corruption and the innodb file was not updated or the frm was not deleted during plugin installation or deinstallation respectively.
3. You changed your storage engine from MyISAM to InnoDB and frm files were left behind that is confusing mysql.
4. Your server crashed, was suddenly rebooted or you had a memory or other issue that caused corruption in the innodb table file.
We have had no other reports of this, so for now please unmark our plugin as broken until you can either confirm that it is our plugin causing this or we figure out that it’s something else.
Let me know if you think it may be one of the above. Also let me know if you’re using the “innodb_file_per_table = 1” option in your my.cnf which will result in each table having it’s own file in innodb or whether you have one monolithic innodb file (the default).
Mark.
Tim sent this to me and I investigated the issue.
The short version: We found a subtle bug in the Wordfence IP validation code and are releasing a fix in the next release. However it appears your IPv6 to IPv4 conversion function may be generating arbitrary IPv4 addresses without respecting address space. e.g. an IP starting with 255.x.x.x is not actually valid. And it may generate things like 10.x.x.x IP’s which are auto-whitelisted by us because they’re private addresses.
The long version:
What I found is a very subtle bug in the Wordfence code. We have a function in lib/wfUtils.php that is called isValidIP().
This function, surprise surprise, checks if IP’s are valid.
In general it’s being doing a good job. But it has a bug. It’s not actually examining IP addresses correctly. It is using pattern matching and integer math, but instead of looking at, in the case of 10.2.3.4 the digits 10, 2, 3 and 4, it examines 10.2.3.4, then 10, then 2 and then 3 and ignores the 4. So the first thing it looks at should be an integer but it’s actually an IP address string.
Well PHP is such a friendly guy that it takes that 10.2.3.4 string which is being erroneously examined and says “OK, I’ll just turn that into a number which contains a decimal point”.
So the result is that so far we’ve been examining only the first 3 octets of any IP to check whether they’re valid and also a string which, as long as it doesn’t start with “255” it passes. As soon as an IP starts with 255, this function was saying “OK it’s actually 255.somethingAfterTheDecimalPoint” and so it fails because it’s out of the 0 to 255 valid range of an IP address.
So that, to make a short story long, is why you are seeing an error with that address starting with 255 and no other IP’s.
What makes this even weirder is that an IP starting with 255 actually is NOT valid as a host address on the Net. So this bug is actually CORRECTLY identifying a bad IP address when it says your 255.x.x.x IP is not valid.
So it’s actually a really cool bug because, while it won’t identify erroneous IP’s with a bad fourth octet, it accidentally adds an additional check to see if the first octet is 255 which is invalid.
I’ve already implemented a fix which will go out with the next release so you won’t get complaints about that 255.x.x.x address anymore and we’re now doing a correct check on the full address including the fourth octet which was being ignored.
However, that 255.x.x.x address you’re seeing actually is not valid on the public Net so you are correctly seeing an error thanks to this weirdly smart bug. But I suspect I know why you’re seeing that address – I think you said you’re running some kind of IPv6 to IPv4 compatibility thing? Well it’s probably generating IPv4 addresses which are not valid on the open internet but are integers in the range of 0 to 2^32 (two to the power of 32) which is the full range of IPv4 address space. If that’s what it’s doing and it’s doing it simplistically then you’re going to see other issues like this thing is going to generate 10.x.x.x addresses which are RFC1918 reserved addresses and are automatically white listed by our software. So you need to make sure this conversion thing is not doing that.
Hope that helps.
Regards,
Mark.
Hi @ferhatakguen,
Please try the following:
Scroll to the bottom of the Wordfence options page. Check the box to disable config caching. This will stop Wordfence from using a file to cache it’s own options which are stored in the database. That way we’re sure that any options you set (like enabling falcon) will be saved and you’re not having an issue caused by using a disk cache to store serialized config data for Wordfence.
Save your options once you make that change.
Then go back to the performance setup page and make sure caching is still enabled. Clear the cache. Make sure that option to insert a comment for debugging is still enabled.
Then hit a page you expect to be cached. Then hit browser reload to get the cached version. Check the HTML source and see if it is the cached version.
Also check the wfcache directory and subdirs to see if anything has been written.
If it’s not caching and nothing has been written, check your web server error log if you have access to that and let me know if there are any errors in there. Also let me know that you’re running Apache or LiteSpeed or Nginx or what your web server is.
Thanks!!
Hi Damon,
We don’t currently support IPv6 and looks like the host is using IPv6 for that request.
Is this a test machine you folks are running?
We’re looking at adding IPv6 support soon.
Regards,
Mark.
Hi,
Your plugin has it’s own email alerting. Then we also run a WordPress security email list which lets us send out global messages about vulnerabilities and security news to our customers.
When you first installed Wordfence we gave you the option to sign up for that during the tour and you must have chosen to sign up with the email address at which this message was received.
We use an outside company called Aweber to send these emails. No one but us has access to your email and every email we send contains unsubscribe instructions at the very top of the email message. So if you want to stop receiving those security alerts just use those instructions to unsubscribe. But in general they’re quite informative and contain some urgent alerts.
Regards,
Mark.
Hi Rene,
This has been a hot button topic for some time. Some more data:
Google has a chart showing user adoption:
https://www.google.com/intl/en/ipv6/statistics.html#tab=ipv6-adoption
And this shows the number of autonomous systems growth:
http://www.ipv6actnow.org/info/statistics/
To give you an idea of how it’s growing in the hosting environment.
The reason implementing IPv6 for us is a big deal is because we store IP addresses in your database and an IPv6 address can’t be stored simply as an unsigned integer – or put differently an integer stored in 32 bits of address space that is always greater than zero.
We need to store those addresses using 128 bits or 16 bytes of space for every address. So we need to change our database schema to accommodate this. It’s a big deal both in complexity, performance impact and risk for introducing new bugs – so it’s something I’ve been postponing for a while.
I can’t make you any promises about when we’ll implement this today because I need to do a full analysis on what the change requires and come up with implementation details. But know that it’s in the works and as you can tell from the charts I posted it is inevitable.
Regards,
Mark.
We provide both firewall and scanning/alerting functionality which work in concert to provide a more secure WordPress website. So back to the original poster’s question, we do provide a firewall and we go deeper than that because we have access to inspect site code, search for malware, find vulnerabilities in code during our scans, do deep inspection of both the filesystem and the database and provide alerting and reporting to give our customers a more secure site.
@perezbox We’re not patching PHP code, so that’s not an issue. We instead provide firewall functionality so that if someone uses the attack vector I mentioned they’re blocked before it hits the vulnerable plugin.
That blog entry installs a vulnerable WP system and then tries to protect it with security plugins using only firewall functionality. The real world scenario is that a WP admin is getting alerted by our plugin that they have out of date themes, plugins or core components or vulnerabilities on their site and they upgrade them or close the holes while we simultaneously provide firewall functionality to prevent exploitation of selected security holes – and as a last resort if a site does get hacked we’ll detect that and help you fix it.
From the blog entry it doesn’t appear that a Wordfence scan was done, either scheduled-daily or manual, which likely would have provided insight into vulnerabilities on the site.
This is appearing on our support forum – I do understand you found it via another route though. So lets cut this short here – I think the original poster’s question has been answered. We’re always interested in outside perspectives and you’re welcome to email me at mark at wordfence.com to continue the conversation.
Regards,
Mark Maunder – Wordfence Founder.
Blog entries like that are frustrating – seems to be a user issue with the reviewer. We have included protection for Timthumb and other specific vulnerabilities via Wordfence scanning. So if you have the vulnerability you’ll get a critical alert. This is more effective than, say, using an .htaccess rule to try to block the vulnerability from being exploited but leaving the vulnerability in place – we get the user to focus on the root cause of the issue and fix that.
Occasionally we will provide real-time patching of an issue via auto-updates. For example yesterday’s release protects against the Slider Revolution issue even if you haven’t upgraded yet. In this case, even though we’d like the user to deal with the root-cause and upgrade their version of Slider Revolution, the amount of PR around the issue creates enough risk that we rolled out additional protection until our customers can upgrade that plugin.
@perezbox Lets try to keep the marketing links to a minimum. We have many other high-profile competitors and partners on this forum making a valuable technical and support contribution and we welcome relevant contributions from you folks too, but lets keep it focused on supporting the community and on this forum specifically, providing customer support for Wordfence.
Regards,
Mark Maunder – Wordfence Founder.
Hi all,
As Tim mentioned we did a major upgrade last night to our infrastructure, so you’re going to have to re-check any issues reported before last night because they are very likely resolved. So @aperson please try a scan, verify that’s working, then view your live traffic page and you should not see that message again.
More info on the upgrade here:
http://www.wordfence.com/blog/2014/09/major-infrastructure-upgrade-completed-and-other-news/
Regards,
Mark.
OK, so we might be able to improve our detection, but for now I’m going to add a switch at the bottom of the Wordfence options in the advanced area that lets you force Falcon to assume you’re using Apache and update .htaccess.
Regards,
Mark.
Hi Andrew,
We try to detect if you’re using Nginx and if we detect that then we show you a suggested config for Nginx.
It sounds like on your configuration that you can use a regular .htaccess and Apache will interpret that. Specifically your apache needs to pay attention to the mod_rewrite rules that we add to .htaccess.
So if we could give you a way to force Falcon to generate an Apache .htaccess for you, do you think that would work
Regards,
Mark.
Please try again. We just completed a major upgrade to our hardware and infrastructure this evening and this should be resolved.
Regards,
Mark.