Linux kernel: CVE-2017-6074: DCCP double-free vulnerability (local root)
This is a good reason for systems running untrusted code to disable module automatic loading. Almost nobody uses DCCP, and as a result, almost nobody <i>looks at</i> the DCCP code, writes bad userspace apps that trigger kernel bugs that get debugged, etc. We rarely see double-frees in the TCP or UDP implementations.<p>On my Debian kernel, CONFIG_IP_DCCP is set to &quot;m&quot; (in &#x2F;boot&#x2F;config-`uname -r`), which means that DCCP support is built as a module. The code isn&#x27;t loaded until the first program tries to call socket(...IPPROTO_DCCP). At that point, the kernel will look at &#x2F;proc&#x2F;sys&#x2F;kernel&#x2F;modprobe and run that program, &#x2F;sbin&#x2F;modprobe by default, to load dccp.ko.<p>Automatic module loading is great when e.g. udev runs and detects what hardware you have, but it&#x27;s probably not something you&#x27;d ever need once a system has completed boot. A very simple hardening measure for machines running untrusted unprivileged code is to echo &#x2F;bin&#x2F;false &gt; &#x2F;proc&#x2F;sys&#x2F;kernel&#x2F;modprobe, late in the boot process (e.g., in &#x2F;etc&#x2F;rc.local).<p>The downside is that system administrator won&#x27;t be able to run tools that require loading modules, of which iptables is probably the most notable one. A better option than &#x2F;bin&#x2F;false is a shell script that logs its arguments to syslog, e.g., `logger -p authpriv.info -- &quot;Refused modprobe $*&quot;`. The sysadmin can manually run modprobe on whatever module name got syslogged (or temporarily set &#x2F;proc&#x2F;sys&#x2F;kernel&#x2F;modprobe back to &#x2F;sbin&#x2F;modprobe). And you can alert on that syslog line to see if there&#x27;s an attack in progress.<p>(Does anyone know if it&#x27;s possible to disable module auto-loading for a tree&#x2F;namespace of processes, e.g. a Docker container, but keep it working for the base system?)