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
| ||
|
Date: Thu, 28 Jul 2016 16:48:32 +0200 From: Florian Westphal <fw@...len.de> To: Brandon Cazander <brandon.cazander@...tapplied.net> Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "edumazet@...gle.com" <edumazet@...gle.com> Subject: Re: PROBLEM: TPROXY and DNAT broken (bisected to 079096f103fa) Brandon Cazander <brandon.cazander@...tapplied.net> wrote: > Hopefully that's enough detail to replicate this issue. I have the full environment set up for both working and non-working kernel versions, so please let me know if there's anything else I can provide. No need, this reproduces easily with this two-line ruleset: -t nat -A PREROUTING -d 192.168.7.20/32 -i eth0 -j DNAT --to-destination 192.168.8.1 -t mangle -A PREROUTING -p tcp -m tcp --dport 8080 -j TPROXY --on-port 9876 --on-ip 0.0.0.0 --tproxy-mark 0x1/0x1 AFAIU the problem is this: SYN: 1. -j TPROXY finds listen sk, redirects to it 2. DNAT takes place (iphdr(skb)->daddr is mangled). 3. tcp stack puts request sk into ehash table. Note that the ehash entry uses the updated/dnatted address. ACK: 1. -j TPROXY finds no established or request socket since it uses iph->daddr but ehash contains dnatted-to address ... so we redirect to the listener socket. Before the ehash change, for skb to listen sk the kernel used to search both the listener socket request queue and the ehash table, using the iphdr daddr (which at this point is the DNAT'ed address). So this used to work because this returns the request sk. After the ehash change we only check syn cookie and will then emit a reset. Eric, AFAICS the only solution for this is to extend TPROXY and obtain the lookup saddr/daddr info from the conntrack entry instead of the ip headers, which should make this work again. Do you agree? Any other suggestions? Thanks!
Powered by blists - more mailing lists