It was found that vsftpd, Very Secure FTP daemon, when the network namespace (CONFIG_NET_NS) support was activated in the kernel, used to create a new network namespace per connection. A remote attacker could use this flaw to cause memory pressure (kernel OOM killer protection mechanism to be activated and potentially terminate vsftpd or arbitrary [vsftpd independent] process, which satisfied the OOM killer process selection algorithm). References: [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=629373 [2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/720095
CVE request: [3] http://www.openwall.com/lists/oss-security/2011/06/06/8
Public PoC (from [2]): ====================== The test is started in this way: $ for i in 1 2 3 4 5 6 7 8 ; do ./feedftp $i >/dev/null & done What is observed during the test is that /proc/vmallocinfo grows continually with lines like the following being added: 0xffffe8ffff800000-0xffffe8ffffa00000 2097152 pcpu_get_vm_areas+0x0/0x790 vmalloc 0xffffe8ffffa00000-0xffffe8ffffc00000 2097152 pcpu_get_vm_areas+0x0/0x790 vmalloc 0xffffe8ffffc00000-0xffffe8ffffe00000 2097152 pcpu_get_vm_areas+0x0/0x790 vmalloc
Created attachment 503287 [details] Relevant feedftp script mentioned in Ubuntu BTS bug [2]
Created attachment 503288 [details] dmesg-oom.32.txt output mentioned in relevant Ubuntu BTS bug [2]
Created attachment 503289 [details] And finally the vmallocinfo.32.tar archive from Ubuntu BTS bug [2]
Created attachment 524135 [details] debian-vsftpd.patch
Statement: Not vulnerable. This issue did not affect the versions of vsftpd as shipped with Red Hat Enterprise Linux 4 or 5. Due to the correction of a crash in vsftpd upon connect (BZ#548802), vsftpd on Red Hat Enterprise Linux 6 is not vulnerable to this flaw either.