Re: possible issue with IPv4 mapped address and $REMOTE_ADDR in CGI

From: Colm MacCarthaigh (colmmacc_at_redbrick.dcu.ie)
Date: 10/29/03

  • Next message: Steve Clement: "Re: Mac OS X vulnerabilities ['Virus checked"]" 
    Date: Wed, 29 Oct 2003 17:01:47 +0000
To: itojun@iijlab.net

    On Wed, Oct 29, 2003 at 02:58:21PM +0900, itojun@iijlab.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@redbrick.dcu.ie        PubKey: colmmacc+pgp@redbrick.dcu.ie  
Web:                                 http://devnull.redbrick.dcu.ie/
  • Next message: Steve Clement: "Re: Mac OS X vulnerabilities ['Virus checked"]"