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: <20031029170147.GA8692@carbon.redbrick.dcu.ie>
Date: Wed, 29 Oct 2003 17:01:47 +0000
From: Colm MacCarthaigh <colmmacc@...brick.dcu.ie>
To: itojun@...lab.net
Cc: bugtraq@...urityfocus.com
Subject: Re: possible issue with IPv4 mapped address and $REMOTE_ADDR in CGI

On Wed, Oct 29, 2003 at 02:58:21PM +0900, itojun@...lab.net wrote:
> 	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).

This has been debated here before, however it is worth noting that 
this is not nearly as straight-forward a solution as you suggest. Some 
platforms do not allow this behaviour (Linux and Tru64 come to mind),
and indeed there are other valid reasons not to use AF_INET6
sockets explicitly.

Consider the logic required to listen on a port using explicit
family sockets in a manner an administrator can cope with;

   1.  Call getaddrinfo with PF_UNSPEC and AI_PASSIVE, get :: and
       0.0.0.0 back in that order.
   2.  Try to create a socket on ::, don't scream too loudly if it
       doesn't work.
   3.  Try to set it to IPv6 only, don't scream too loudly if it doesn't
       work
   4.  Try to bind() and listen() to it, don't scream too loudly if it
       doesn't work.
   5.  If 2 and 4 were successful, but 3 wasn't; Don't even try to listen
       on 0.0.0.0.
   6.  Otherwise try to listen on 0.0.0.0 and bomb out on error.

Now consider the logic required if you allow the use of mapped 
addresses;

   1. Call getaddrinfo with PF_UNSPEC and AI_PASSIVE, get ::
      and 0.0.0.0 back in that order.
   2. Try to bind to the first one that works.

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. 

Allthough a much weaker argument, some would point out that an additional
socket to listen on can have a performance effect, particularly on
select/poll based implementations. To be honest, I doubt this is a
sigificant factor, but some feel differently and it is worth noting.

Whilst I agree that the world would certainly be simpler without
mapped address, and that it may be appropriate to describe them
as harmful, they do exist and are inescaple in terms of practical
programming.

Since mapped addresses are a fact of life and must be handled for
applications to be considered portable, it is better to handle them more
considerately than not at all. Explicitly checking for mapped-addresses
and rendering them available in a suitable manner is not hard.

For the record, Apache's httpd renders mapped addresses available in
such a manner, and does not exhibit the problem you describe.

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