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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 16 Nov 2017 11:49:00 +0200
From:   Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
To:     Sarah Newman <srn@...mr.com>, netdev@...r.kernel.org
Cc:     roopa <roopa@...ulusnetworks.com>
Subject: Re: [PATCH] net: bridge: add max_fdb_count

On 16/11/17 11:20, Sarah Newman wrote:
> 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/
> 

Having L2 access means many more things are possible, that being said I'm not
against adding the limit just need to make it optional with the default either
being no limit or a very high one (e.g. u32 max).

> 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.

The same argument applies to anyone who wants to limit their fdbs, and the
standard way to add new options in the Linux bridge which affect normal operations
is to keep the current behaviour and enable the new one on user request in order to
avoid breaking already existing setups.
In fact we try very hard to keep existing setups running.

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