linux-kernel - Re: [PATCH net v4] net: netfilter: Fix port selection of FTP for NF_NAT_RANGE_PROTO

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] [day] [month] [year] [list]

Message-ID: <20210917140408.GD15906@breakpoint.cc>
Date:   Fri, 17 Sep 2021 16:04:08 +0200
From:   Florian Westphal <fw@...len.de>
To:     Cole Dishington <Cole.Dishington@...iedtelesis.co.nz>
Cc:     "fw@...len.de" <fw@...len.de>,
        "coreteam@...filter.org" <coreteam@...filter.org>,
        "netfilter-devel@...r.kernel.org" <netfilter-devel@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "pablo@...filter.org" <pablo@...filter.org>,
        Anthony Lineham <Anthony.Lineham@...iedtelesis.co.nz>,
        "shuah@...nel.org" <shuah@...nel.org>,
        "kadlec@...filter.org" <kadlec@...filter.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Blair Steven <Blair.Steven@...iedtelesis.co.nz>,
        Scott Parlane <Scott.Parlane@...iedtelesis.co.nz>
Subject: Re: [PATCH net v4] net: netfilter: Fix port selection of FTP for
 NF_NAT_RANGE_PROTO_SPECIFIED

Cole Dishington <Cole.Dishington@...iedtelesis.co.nz> wrote:
> On Thu, 2021-09-16 at 13:26 +0200, Florian Westphal wrote:
> > >range_info.max_proto.all) {
> > 		min = 1;
> > 		max = 65535;
> > 		range_size = 65535;
> > 	} else {
> > 		min = ntohs(nat->range_info.min_proto.all);
> > 		max = ntohs(nat->range_info.max_proto.all);
> > 		range_size = max - min + 1;
> > 	}
> 
> The original code defined the range as [ntohs(exp->saved_proto.tcp.port), 65535]. The above would
> cause a change in behaviour, should we try to avoid it?

Oh indeed, oversight on my part.  Good question, current loop
is not good either as it might take too long to complete.

Maybe best to limit/cap the range to 128, e.g. try to use port
as-is, then pick a random value between 1024 and 65535 - 128,
make 128 tries and if all is taken, error out.

I will leave it up to you on how you'd like to handle this.

One way would be to make a small preparation patch and then
built the range patch on top of it.