netdev - Re: removing conntrack helper toggle to enable auto-assignment [was Re: b118509076b3 (probably) breaks my firewall]

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: <fc8792bf-2d67-496a-6d90-940de21694d9@googlemail.com>
Date:   Tue, 20 Sep 2022 07:49:23 +0100
From:   Chris Clayton <chris2553@...glemail.com>
To:     Jakub Kicinski <kuba@...nel.org>, Florian Westphal <fw@...len.de>
Cc:     Pablo Neira Ayuso <pablo@...filter.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        regressions@...ts.linux.dev, netfilter-devel@...r.kernel.org,
        coreteam@...filter.org
Subject: Re: removing conntrack helper toggle to enable auto-assignment [was
 Re: b118509076b3 (probably) breaks my firewall]



On 19/09/2022 21:57, Jakub Kicinski wrote:
> On Mon, 19 Sep 2022 22:23:10 +0200 Florian Westphal wrote:
>> Jakub Kicinski <kuba@...nel.org> wrote:
>>> On Sat, 10 Sep 2022 04:02:18 +0200 Pablo Neira Ayuso wrote:  
>>>> Disagreed, reverting and waiting for one more release cycle will just
>>>> postpone the fact that users must adapt their policies, and that they
>>>> rely on a configuration which is not secure.  
>>>
>>> What are the chances the firewall actually needs the functionality?  
>>
>> Unknown, there is no way to tell.
> 
> Chris, is your firewall based on some project or a loose bunch of
> scripts you wrote?
> 

It's a script executed at boot via sysv init. I wrote the script myself following a HOWTO that I found somewhere on the
net. I very rarely run an ftp server on my laptop but I do occasionally need to get files from a remote ftp server.

I eventually figured out what needed to be done to restore my firewall to working order. I had no clue that the change
was coming. I built my system using the Linux From Scratch recipes in 2017. I update the software I have installed
whenever newreleases become available so it's like my own rolling release. But it is very stable. I inspect the output
from the boot log and dmesg fairly regularly (at least once a week), but had never seen anything about this deprecation
until my firewall failed to load when the write to the now-removed variable was attempted.

So I guess I'm an unusual case in that I don't rely on distro maintainers to fix up stuff like this on the rare
occasions it comes along. On reflection, I'd say leave it be - as I said earlier, it just seemed rather late in the 6.0
development cycle for this to pop up.
> I had little exposure to NF/conntrack in my career but I was guessing 
> for most users one of the two cases:
> 
>  - the system is professionally (i.e. someone is paid) maintained, 
>    so they should have noticed the warning and fixed in the last 10 yrs
> 
>  - the system is a basic SOHO setup which is highly unlikely to see much
>    more than TLS or QUIC these days
> 
> IOW the intersection of complex traffic and lack of maintenance is
> small.
> 
>> In old times, it was enough (not tested, just for illustration):
>>
>> iptables -A FORWARD -p tcp -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
>>
>> and load nf_conntrack_ftp (or whatever).  Module will auto-snoop traffic
>> on tcp port 21 for ftp commands, if it finds some, it auto-installs dynamic
>> 'expectation entries', so when data connection comes it will hit RELATED rule
>> above.
>>
>> This stopped working years ago, unless you did set the (now removed)
>> knob back to 1.
>>
>> Assuming iptables, users would need to do something like
>> iptables -t raw -A PREROUTING -p tcp --dport 21 -d $ftpaddr -j CT --helper "ftp"
>>
>> to tell that packets/connections on tcp:21 need to be examined for ftp commands.
> 
> Thanks for the explainer! 
> 
>>> Perhaps we can add the file back but have it do nothing?  
>>
>> I think its even worse, users would think that auto-assign is enabled.
> 
> Well, users should do the bare minimum of reading kernel logs :(
> 
> I think we should do _something_ because we broke so many things 
> in this release if we let this rot until its smell reaches Linus -
> someone is getting yelled at...
> 
> Now, Linus is usually okay with breaking uAPI if there is no other 
> way of preventing a security issue. But (a) we break autoload of
> all helpers and we only have security issue in one, and (b) not loading
> the module doesn't necessarily mean removing the file (at least IMHO).
> We have a bunch of dead files in proc already, although perhaps the 
> examples I can think of are tunables.