netdev - Re: : getsockopt(fd, SOL_IP, SO_ORIGINAL_DST, sa, &salen) is in fact sometimes returning the source IP instead the destination IP

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: <20190112160400.dblitzk2ftlfzryd@breakpoint.cc>
Date:   Sat, 12 Jan 2019 17:04:00 +0100
From:   Florian Westphal <fw@...len.de>
To:     Lukas Tribus <lists@...i.eu>
Cc:     Florian Westphal <fw@...len.de>,
        Mohandass Roobesh <Roobesh_Mohandass@...fee.com>,
        Willy Tarreau <w@....eu>, netdev@...r.kernel.org
Subject: Re: : getsockopt(fd, SOL_IP, SO_ORIGINAL_DST, sa, &salen) is
 in fact sometimes returning the source IP instead the destination IP

Lukas Tribus <lists@...i.eu> wrote:
> The application (haproxy) needs to know the original destination IP
> address, however it does not know whether -j REDIRECT was used or not.
> Because of this the application always queries SO_ORIGINAL_DST, and
> this includes configurations without -j REDIRECT.
> 
> Are you saying the behavior of SO_ORIGINAL_DST is undefined when not
> used with -j REDIRECT and that this issue does not happen when -j
> REDIRECT is actually used?

No, thats not what I said.  Because OP provided a link that mentions
TPROXY, I concluded OP was using TPROXY, so I pointed out that the
error source can be completely avoided by not using SO_ORIGINAL_DST.

As I said, SO_ORIGINAL_DST returns the dst address of
the original direction *as seen by conntrack*.

In case REDIRECT or DNAT was used, the address returned is the on-wire
one, before DNAT rewrite took place.

Therefore, SO_ORIGINAL_DST is only needed when REDIRECT or DNAT was
used. If no DNAT rewrite takes place, sockaddr returned by accept or
getsockname can be used directly and SO_ORIGINAL_DST isn't needed.
The returned address should be identical to the one given by accept().

If SO_ORIGINAL_DST returns the reply, then conntrack picked up
a reply packet as the first packet of the connection, so it believes
originator is the responder and vice versa.

One case where this can happen is when nf_conntrack_tcp_loose
(mid-stream pickup) is enabled.

This is not a haproxy bug.

Only thing that haproxy could is to provide a knob to make it only
use addresses returned by accept, rather than relying on
SO_ORIGINAL_DST for those that use TPROXY to do MITM interception.