<story><title>Linux kernel: CVE-2017-6074: DCCP double-free vulnerability (local root)</title><url>http://seclists.org/oss-sec/2017/q1/471</url></story><parent_chain><item><author>geofft</author><text>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 &lt;i&gt;looks at&lt;/i&gt; 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.&lt;p&gt;On my Debian kernel, CONFIG_IP_DCCP is set to &amp;quot;m&amp;quot; (in &amp;#x2F;boot&amp;#x2F;config-`uname -r`), which means that DCCP support is built as a module. The code isn&amp;#x27;t loaded until the first program tries to call socket(...IPPROTO_DCCP). At that point, the kernel will look at &amp;#x2F;proc&amp;#x2F;sys&amp;#x2F;kernel&amp;#x2F;modprobe and run that program, &amp;#x2F;sbin&amp;#x2F;modprobe by default, to load dccp.ko.&lt;p&gt;Automatic module loading is great when e.g. udev runs and detects what hardware you have, but it&amp;#x27;s probably not something you&amp;#x27;d ever need once a system has completed boot. A very simple hardening measure for machines running untrusted unprivileged code is to echo &amp;#x2F;bin&amp;#x2F;false &amp;gt; &amp;#x2F;proc&amp;#x2F;sys&amp;#x2F;kernel&amp;#x2F;modprobe, late in the boot process (e.g., in &amp;#x2F;etc&amp;#x2F;rc.local).&lt;p&gt;The downside is that system administrator won&amp;#x27;t be able to run tools that require loading modules, of which iptables is probably the most notable one. A better option than &amp;#x2F;bin&amp;#x2F;false is a shell script that logs its arguments to syslog, e.g., `logger -p authpriv.info -- &amp;quot;Refused modprobe $*&amp;quot;`. The sysadmin can manually run modprobe on whatever module name got syslogged (or temporarily set &amp;#x2F;proc&amp;#x2F;sys&amp;#x2F;kernel&amp;#x2F;modprobe back to &amp;#x2F;sbin&amp;#x2F;modprobe). And you can alert on that syslog line to see if there&amp;#x27;s an attack in progress.&lt;p&gt;(Does anyone know if it&amp;#x27;s possible to disable module auto-loading for a tree&amp;#x2F;namespace of processes, e.g. a Docker container, but keep it working for the base system?)</text></item></parent_chain><comment><author>blockoperation</author><text>...or just roll your own kernel with CONFIG_MODULES=n.&lt;p&gt;If you only need a specific set of modules, you might as well just build them in and just forget LKMs altogether.&lt;p&gt;It&amp;#x27;s not very convenient when you run into some obscure hardware&amp;#x2F;fs&amp;#x2F;protocol, but depending on your use case, that might not be an issue (and even in the rare case where it does come up, it&amp;#x27;s not the end of the world – a minimal kernel build only takes a couple of minutes on a reasonably fast machine).&lt;p&gt;The only case where LKMs really seem necessary (besides in generic distro kernels) is for module development&amp;#x2F;debugging, but you&amp;#x27;re probably not going to do that with a production kernel anyway.</text></comment>
<story><title>Linux kernel: CVE-2017-6074: DCCP double-free vulnerability (local root)</title><url>http://seclists.org/oss-sec/2017/q1/471</url></story><parent_chain><item><author>geofft</author><text>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 &lt;i&gt;looks at&lt;/i&gt; 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.&lt;p&gt;On my Debian kernel, CONFIG_IP_DCCP is set to &amp;quot;m&amp;quot; (in &amp;#x2F;boot&amp;#x2F;config-`uname -r`), which means that DCCP support is built as a module. The code isn&amp;#x27;t loaded until the first program tries to call socket(...IPPROTO_DCCP). At that point, the kernel will look at &amp;#x2F;proc&amp;#x2F;sys&amp;#x2F;kernel&amp;#x2F;modprobe and run that program, &amp;#x2F;sbin&amp;#x2F;modprobe by default, to load dccp.ko.&lt;p&gt;Automatic module loading is great when e.g. udev runs and detects what hardware you have, but it&amp;#x27;s probably not something you&amp;#x27;d ever need once a system has completed boot. A very simple hardening measure for machines running untrusted unprivileged code is to echo &amp;#x2F;bin&amp;#x2F;false &amp;gt; &amp;#x2F;proc&amp;#x2F;sys&amp;#x2F;kernel&amp;#x2F;modprobe, late in the boot process (e.g., in &amp;#x2F;etc&amp;#x2F;rc.local).&lt;p&gt;The downside is that system administrator won&amp;#x27;t be able to run tools that require loading modules, of which iptables is probably the most notable one. A better option than &amp;#x2F;bin&amp;#x2F;false is a shell script that logs its arguments to syslog, e.g., `logger -p authpriv.info -- &amp;quot;Refused modprobe $*&amp;quot;`. The sysadmin can manually run modprobe on whatever module name got syslogged (or temporarily set &amp;#x2F;proc&amp;#x2F;sys&amp;#x2F;kernel&amp;#x2F;modprobe back to &amp;#x2F;sbin&amp;#x2F;modprobe). And you can alert on that syslog line to see if there&amp;#x27;s an attack in progress.&lt;p&gt;(Does anyone know if it&amp;#x27;s possible to disable module auto-loading for a tree&amp;#x2F;namespace of processes, e.g. a Docker container, but keep it working for the base system?)</text></item></parent_chain><comment><author>joser</author><text>Not what you ask, but you can blacklist that module with a fake install.&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;wiki.debian.org&amp;#x2F;KernelModuleBlacklisting&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;wiki.debian.org&amp;#x2F;KernelModuleBlacklisting&lt;/a&gt;</text></comment>