Blacklisting/Disabling AF_<arcane networking>

[Tim Gardner]

On 11/30/2010 11:31 AM, Kees Cook wrote:
> Hi Andy,
>
> On Tue, Nov 30, 2010 at 02:29:56PM +0000, Andy Whitcroft wrote:
>> At UDS there was some discussion about how we have almost all of the
>> address family support AF_* built as modules.  This means that a simple
>> socket(AF_ARCANE_THING, ...) or indeed an incoming packet will trigger
>> loading of these modules and expose us to any security issues in those
>> modules.
>>
>> The UDS discussion suggested that at least blacklisting any un-common
>> address families might be appropriate; a user requiring this would then
>> simply add the module to /etc/modules to re-enable it.  Futher discussion
>> on IRC and other places has suggested that some of these address families
>> do not even warrant building at all.  For example ECONET supports a
>> network which is very likely not even in existance let alone common on
>> our target hardware.
>>
>> In the face of recent security alerts I am inclined to think that is an
>> entirly reasonable approach and am keen to understand any issues this
>> may cause.   How can we progress with this?
>
> Totally agreed. My impulse is to pursue Dan Rosenberg's "do not autoload
> modules" approach:
> https://lkml.org/lkml/2010/11/7/212
>
> But without that, we could also ship a file
> /etc/modprobe.d/blacklist-rarenet.conf that listed all the aliases, which
> is what Debian started doing:
>
> alias net-pf-19 off
> alias net-pf-21 off
> ...
>
>
> -Kees
>

As I understand it, there are 2 ways for an address family protocol to 
get loaded; 1) open a socket with an address family specification (e.g. 
AF_ECONET), or 2) receive a packet with an address family for which no 
protocol handler is loaded.

Blacklisting the packet family number ala Debian only solves part of the 
problem. While it reduces the attack surface, there is still a 
possibility for DOS because modprobe is still launched for each socket 
open attempt, likely emitting a great deal of noise in dmesg. I expect 
the same happens for packet reception.

Does Dan's patch fix both of those cases? Assuming my assumptions are 
correct...

rtg
-- 
Tim Gardner tim.gardner at canonical.com