Bug tracker

This ticket has been moved to our new tracker. Open Ticket PHPBB3-9466 now.

"Registered from IP" contains invalid IP address (fix completed in vcs)

I recently found a registered user on my forum where the ACP claims the "registered from IP" is:

10.216.6.118, 161.148.54.145

The user_ip field in the database contains this exact string. When clicking the IP or Whois links in the ACP, PHP throws an error:

[phpBB Debug] PHP Notice: in file /includes/acp/acp_users.php on line 925: gethostbyaddr() [function.gethostbyaddr]: Address is not a valid IPv4 or IPv6 address

and

[phpBB Debug] PHP Notice: in file /includes/acp/acp_users.php on line 60: gethostbyaddr() [function.gethostbyaddr]: Address is not a valid IPv4 or IPv6 address

As another consequence, attempting to ban the user by IP fails with a green info block saying, "No IP addresses or hostnames defined".

I have "Validated X_FORWARDED_FOR header" enabled, and I think this might be related.

See attached screenshot for the IP appearing in ACP.

This bug has been placed in the ACP component, since it is the one most affected, but probably stems from Sessions.
codifier.png (315.45 KB)

Comments / History

Moved ticket from project "phpBB 3.0.x" (Security tracker) to "phpBB 3.0.x" (Bug tracker)

Action performed by Kellanved (Former Team Member) on Aug 3rd 2009, 20:04

Posted by Parasytic on Aug 3rd 2009, 20:39

Some additional information: my host's Apache access logs show the same IP address for that client (two IPs seperated by a comma).

Posted by bantu (3.0 Release Manager) on Aug 3rd 2009, 22:21

X-Forwarded-For is usually seperated by a space, not a comma. I guess that's where the problem is.

Edited post #173715

Action performed by bantu (3.0 Release Manager) on Aug 3rd 2009, 22:33

Changed ticket severity from "Uncategorised/normal" to "Severe"

Action performed by bantu (3.0 Release Manager) on Aug 12th 2009, 01:45

Changed ticket status from "New" to "Awaiting team input"

Action performed by ToonArmy (Development Team Member) on Aug 12th 2009, 15:10

Edited post #175585

Action performed by ToonArmy (Development Team Member) on Aug 12th 2009, 15:11

Posted by suitlocal on Aug 12th 2009, 19:23

where is post 175585?

anyway i unable to reproduce. my first thought is caching proxy but on second thought i do not tihnk so. caching proxies can make all remote_addr same and may append original remote_addr to x_forwarded_for to compensate. but i not seen this b4.

generally speaking remote_addr can not be faked with tcp. client sends syn and if it can not get syn-ack back (which it would not with fake ip) it will not work. never mind fact that remote_addr in ipv4 can only be 32 bits. if you try to add ascii string to it routers no know how to route.

Posted by bantu (3.0 Release Manager) on Aug 13th 2009, 00:45

My initial guess was completly wrong. I thought this was about something else. Sorry.

Edited post #175905

Action performed by nickvergessen (Development Team Member) on Aug 13th 2009, 10:45

Posted by naderman (Development Team Leader) on Aug 13th 2009, 16:58

One possible cause for this is that the web hoster uses some http cache/proxy and has apache configured to use the forwarded for header as the actual IP, but not configured the cache/proxy in a way so that it will overwrite any existing content of the header with the actual IP.

We should probably validate the IP address in REMOTE_ADDR to prohibit this. The regex for a valid IPv4 address is relatively simple but the one for an IPv6 address is somewhat more complex so maybe we should come up with some simpler way of validating the address.

Posted by bantu (3.0 Release Manager) on Aug 15th 2009, 19:01

naderman, what would you suggest to do if validation fails?

Assigned ticket to user "Acyd Burn"

Action performed by Acyd Burn (Server Manager) on Aug 20th 2009, 08:41

Posted by Acyd Burn (Server Manager) on Aug 20th 2009, 08:42

This ticket would normally be "will not fix", but i have gone ahead and at least added some basic checks.

Linked ticket with changeset: r10020

Action performed by Acyd Burn (Server Manager) on Aug 20th 2009, 08:43

Changed ticket severity from "Severe" to "Uncategorised/normal"

Action performed by Acyd Burn (Server Manager) on Aug 20th 2009, 08:43

Changed ticket status from "Awaiting team input" to "Fix completed in SVN"

Action performed by Acyd Burn (Server Manager) on Aug 20th 2009, 08:43

Posted by Parasytic on Oct 21st 2009, 17:59

For future reference, this is indeed a problem with the proxy setup by my host (nearlyfreespeech.net) A similar problem was effecting Mediawiki, as well: https://bugzilla.wikimedia.org/show_bug.cgi?id=18173#c8

Ticket details

Related SVN changesets