possible issue with IPv4 mapped address and $REMOTE_ADDR in CGI

[itojun@iijlab.net]

because of the difference in http server in handling IPv4 mapped
address (IPv4 traffic goes into the system into AF_INET6 socket),
the peer's address passed by $REMOTE_ADDR to CGI script can vary
between the http server.
some http server would pass IPv4 mapped address as is (::ffff:10.1.1.1),
and some http server would pass IPv4 mapped address converted into
IPv4 address (10.1.1.1). this complexity could confuse CGI program
writers and could open up vulnerability if CGI program uses
$REMOTE_ADDR for authentication.

solution: do not accept IPv4 traffic by using AF_INET6 socket. use
AF_INET socket (http server should listen to AF_INET and AF_INET6
socket explicitly). draft-cmetz-v6ops-v4mapped-api-harmful-01.txt
talks more about this issue.

itojun

[der Mouse]

> Now consider the logic required if you allow the use of mapped
> addresses; [...]

> It must be noted that this approach is generally simpler (and to my
> mind, less error-prone), portable (certainly within *nix, though not
> win32) and AF forwards-compatible.

It's AF forwards-compatible only if every new AF includes a
mapped-addresses version of all previous ones.

I don't expect this to be true. Indeed, it isn't now, as far as I can
tell, unless you restrict yourself to INET and INET6.

Also, note that the application can get whichever set of semantics it
prefers by explicitly setting the V6ONLY option on the socket; the
tempest in a teapot is strictly about which way the default should be -
and since there are OSes that disagree on the default, well-written
application code won't depend on the default, instead explicitly
setting the option whenever doing things the option affects.

/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse@rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

[Colm MacCarthaigh]

On Wed, Oct 29, 2003 at 01:06:55PM -0500, der Mouse wrote:
> Also, note that the application can get whichever set of semantics it
> prefers by explicitly setting the V6ONLY option on the socket;

My main point is that this is not the case. The V6ONLY socket option
is not honoured by some widely-deployed Operating Systems.

Although the situation is rapidly improving, I would argue that
it is currently still worth accompanying a recommendation of using
explicit AF sockets with the excellent recommendation from section
4 of the I-D;

"In EVERY application, check for IPv4-mapped addresses wherever
addresses enter code paths under your control (i.e., are returned from
system calls, or from library calls, or are input from the user or a
file), and handle them in an appropriate manner. This approach is
difficult in reality, and there is no way to determine whether it has
been followed fully."

Proposing "do not accept IPv4 traffic by using AF_INET6 socket" without
even a "where available" qualifier as a solution is unsuitable and
unrealistic. It is a simple fact of life that current application
developers have to live with the fact that some OS's do not support
this behaviour.

--
colmmacc@redbrick.dcu.ie PubKey: colmmacc+pgp@redbrick.dcu.ie
Web: http://devnull.redbrick.dcu.ie/