A security flaw has been discovered in D-Link DIR-823G 1.0.2B05. The affected element is an unknown function of the file /etc/vsftpd.conf of the component vsftpd. Performing a manipulation results in least privilege violation. The attack can be initiated remotely. The exploit has been released to the public and may be used for attacks.

A flaw was found in vsftpd. This vulnerability allows a denial of service (DoS) via an integer overflow in the ls command parameter parsing, triggered by a remote, authenticated attacker sending a crafted STAT command with a specific byte sequence.

Vadim Ponomarev (ccrssaa at karelia.ru), report a pid namespace leak caused by vsftpd.

Detailed discussion can be found in: https://bugzilla.novell.com/showbug.cgi?id=757783

Introduced by: http://git.kernel.org/linus/423e0ab086ad8b33626e45fa94ac7613146b7ffa

Upstream commit: http://git.kernel.org/linus/905ad269c55fc62bee3da29f7b1d1efeba8aa1e1

Steps to reproduce: https://bugzilla.novell.com/showbug.cgi?id=757783#c0

Acknowledgements:

Red Hat would like to thank Vadim Ponomarev for reporting this issue.

There exists a integer overflow to buffer overflow vulnerability within tzfileread function of the GNU C Library. This vulnerability was published by dividead early in 2009 in the following blog post:

http://dividead.wordpress.com/2009/06/01/glibc-timezone-integer-overflow/

In December 3, Kingcope, at Full Disclosure Mailing List, noted vsftpd as one possible attack vector for this issue:

http://lists.grok.org.uk/pipermail/full-disclosure/2011-December/084452.html

taskstats information may be used for gathering private information. E.g. for openssh and vsftpd daemons readcharacters/writecharacters may be used to learn the precise password length. Restrict it to processes being able to ptrace the target process. For TASKSTATSCMDATTRREGISTERCPUMASK the fix is euid check instead of a ptrace check as the handler is processed in the context of the target process, not the listener process'. When ptracetaskmayaccesscurrent() is introduced, it should be used instead of euid check. Currently there is a small race when a process temporarily changes its euid (e.g. to access user's files), until the process sets euid back user's processes may gather privileged process' statistics.

taskstats authorizedkeys presence infoleak PoC http://seclists.org/oss-sec/2011/q2/659

[0/2] restrict statistics information to user https://lkml.org/lkml/2011/6/24/88 [1/2] proc: restrict access to /proc/PID/io (CVE-2011-2495) https://patchwork.kernel.org/patch/916032/ [2/2] taskstats: restrict access to user (CVE-2011-2494) https://patchwork.kernel.org/patch/916042/

http://article.gmane.org/gmane.comp.security.oss.general/5337 Linus suggested returning accounting information at a 1k granularity instead.

Acknowledgements:

Red Hat would like to thank Vasiliy Kulikov of Openwall for reporting this issue.

/proc/PID/io may be used for gathering private information. E.g. for openssh and vsftpd daemons wchars/rchars may be used to learn the precise password length.

[0/2] restrict statistics information to user https://lkml.org/lkml/2011/6/24/88 [1/2] proc: restrict access to /proc/PID/io (CVE-2011-2495) https://patchwork.kernel.org/patch/916032/ [2/2] taskstats: restrict access to user (CVE-2011-2494) https://patchwork.kernel.org/patch/916042/

taskstats authorizedkeys presence infoleak PoC http://seclists.org/oss-sec/2011/q2/659

Acknowledgements:

Red Hat would like to thank Vasiliy Kulikov of Openwall for reporting this issue.

It was found that vsftpd, Very Secure FTP daemon, when the network namespace (CONFIGNETNS) 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

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 pcpugetvmareas+0x0/0x790 vmalloc 0xffffe8ffffa00000-0xffffe8ffffc00000 2097152 pcpugetvmareas+0x0/0x790 vmalloc 0xffffe8ffffc00000-0xffffe8ffffe00000 2097152 pcpugetvmareas+0x0/0x790 vmalloc

vsftpd bug: https://bugzilla.redhat.com/showbug.cgi?id=711134

Proposed patches (but has connection rates problem): http://patchwork.ozlabs.org/patch/88217/

Description of problem: There is a memory leak that causes memory to be allocated but not freed. When the denyfile option is set, it is possible to easily exploit this. This is a regression caused by applied patch in bz174764. Problem also exists in FC-6, F-7, F-8 and fedora/devel. Attached is a patch to solve the problem.

Version-Release number of selected component (if applicable): vsftpd-2.0.5-10.el5

How reproducible: always

Steps to Reproduce: echo denyfile=foo >> /etc/vsftpd/vsftpd.conf service vsftpd restart

$ cat > memtest.sh << EOF #!/bin/bash echo USER anonymous echo PASS foo

while [ 1 ]; do echo CWD pub echo CWD .. done EOF

$ chmod 700 memtest.sh $ ./memtest.sh | telnet localhost 21 > /dev/null

Actual results: vsftpd starts to allocate memory that will never be freed.

Expected results:

Additional info: It is possible that the memory leak can be exploited by other means, or with other vsftpd.conf options. This was not investigated into more depth.