bugtraq - Re: possible issue with IPv4 mapped address and $REMOTE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <200310291814.NAA18908@Sparkle.Rodents.Montreal.QC.CA>
Date: Wed, 29 Oct 2003 13:06:55 -0500 (EST)
From: der Mouse <mouse@...ents.Montreal.QC.CA>
To: bugtraq@...urityfocus.com
Subject: Re: possible issue with IPv4 mapped address and $REMOTE_ADDR in CGI

> 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@...ents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B