netdev - Re: [PATCH] netfilter: nf_nat: avoid double nat for loopback

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: <alpine.LFD.2.00.1106072234140.1619@ja.ssi.bg>
Date:	Tue, 7 Jun 2011 22:46:47 +0300 (EEST)
From:	Julian Anastasov <ja@....bg>
To:	Patrick McHardy <kaber@...sh.net>
cc:	Pablo Neira Ayuso <pablo@...filter.org>,
	netfilter-devel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH] netfilter: nf_nat: avoid double nat for loopback


	Hello,

On Tue, 7 Jun 2011, Patrick McHardy wrote:

> On 04.06.2011 16:02, Julian Anastasov wrote:
> > 
> > 	Avoid double NAT and seq adjustment for loopback
> > traffic because it causes silent repetition of TCP data. One
> > example is passive FTP with DNAT rule and difference in the
> > length of IP addresses.
> > 
> > 	This patch adds checks if packet is sent and
> > received via loopback device. As the same conntrack is used
> > both for outgoing and incoming direction, we restrict NAT,
> > seq adjustment and confirmation to happen only in
> > outgoing direction (OUTPUT and POSTROUTING).
> > 
> > Signed-off-by: Julian Anastasov <ja@....bg>
> > ---
> > 
> > 	As the check is not so cheap, another alternative
> > is to add new skb flag, eg. "loopback", that can be set in 
> > drivers/net/loopback.c, loopback_xmit(). May be there is space
> > for it in flags2?
> 
> I don't think we should be adding code specifically needed for netfilter
> to the loopback driver if we can avoid it. I don't think we need to
> actually avoid calling nf_nat_packet twice, that shouldn't do any harm,
> just the sequence number adjustment. So we could add the loopback check

	Yes, may be calling nf_nat_packet is not fatal.

> to the IPS_SEQ_ADJUST_BIT case to at least avoid it in some cases.
> Would that work or am I missing something?

	Logically, the new check can be after
test_bit(IPS_SEQ_ADJUST_BIT, &ct->status). But I suspect
some modules adjust seqs in the helper->help call,
for example, sip_help_tcp if I'm correctly reading the
code.

Regards

--
Julian Anastasov <ja@....bg>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html