netdev - Re: [PATCH] net: bridge: add max_fdb

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]

Date:   Thu, 16 Nov 2017 01:20:18 -0800
From:   Sarah Newman <srn@...mr.com>
To:     Nikolay Aleksandrov <nikolay@...ulusnetworks.com>,
        netdev@...r.kernel.org
Cc:     roopa <roopa@...ulusnetworks.com>
Subject: Re: [PATCH] net: bridge: add max_fdb_count

On 11/15/2017 11:31 PM, Nikolay Aleksandrov wrote:
> On 15/11/17 21:27, Sarah Newman wrote:
>> Current memory and CPU usage for managing bridge fdb entries is unbounded.
>> Add a parameter max_fdb_count, controlled from sysfs, which places an upper
>> limit on the number of entries. Defaults to 1024.
>>
>> When max_fdb_count is met or exceeded, whether traffic is sent out a
>> given port should depend on its flooding behavior.
>>
>> This may instead be mitigated by filtering mac address entries in the
>> PREROUTING chain of the ebtables nat table, but this is only practical
>> when mac addresses are known in advance.
>>
> 
> One alternative solution: if limit is the only requirement it could be done
> in user-space (even with a shell script) looking at fdb notifications and
> if you reach some limit then remove the learning flag from ports, later if
> enough expire turn it back on. In fact you can make any policy and if you
> catch an offending port - you can disable only its learning flag and leave the
> rest.

Leaving such a trivial DOS in the kernel doesn't seem like a good idea to me,
but I suppose it hasn't bothered anyone else up to now except this person
back in 2013: https://www.keypressure.com/blog/linux-bridge-port-security/

I note that anyone who would run up against a too-low limit on the maximum
number of fdb entries would also be savvy enough to fix it in a matter of
minutes. They could also default the limit to U32_MAX in their particular
distribution if it was a configuration option.

At the moment there is not even a single log message if the problem doesn't
result in memory exhaustion.

--Sarah