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.
