Date: Wed, 2 Mar 2016 13:16:06 -0500 (EST) From: Vladis Dronov <vdronov@...hat.com> To: oss-security@...ts.openwall.com, cve-assign@...re.org Subject: Re: Re: CVE request -- linux kernel: pipe: limit the per-user amount of pages allocated in pipes Hello, Let me try to comment the below: >> However, the commit indicates that there isn't a mandatory behavior >> change ("The limit are controlled by two new sysctls : >> pipe-user-pages-soft, and pipe-user-pages-hard. Both may be disabled >> by setting them to zero.") -- suggesting a possible interpretation as >> a design enhancement, not a vulnerability fix. I believe, there is a behavior change, as the default values of pipe-user-pages-soft and pipe-user-pages-hard: +unsigned long pipe_user_pages_hard; # is 0 +unsigned long pipe_user_pages_soft = PIPE_DEF_BUFFERS * INR_OPEN_CUR; # is 16k pages == 64MiB allows only 64MiB of unread data fed into the pipes per user. The previous unrestricted behavior is possible if only both pipe-user-pages-soft and pipe-user-pages-hard is set to zero. >> Also, the discussion >> doesn't directly comment on whether the "filling large pipes" scenario >> has a security impact that is otherwise unavailable to the attacker, >> e.g., it doesn't discuss the difference between the attacker choosing >> to fill 4000 pipes and the attacker choosing to use mmap. An attacker using this method consumes a kernel memory, which is not directly accounted to any per-user limit. Indirectly an attacker is limited by max-open-files and max-processes per-user limits, but their defaults on modern distributions allow attacker to consume approx. 4TiB or more of the kernel memory. I believe that in other way (surely, not counting yet-unfixed flaws of this type) an attacker cannot unrestrictedly consume the kernel memory. For example, mmap()ed memory mentioned is accounted to per-user virtual memory limit: $ uname -r 4.4.0-0.rc6.git0.1.fc24.x86_64 $ ulimit -v 612000 $ ./mmaptest # just mmap()s 512 MiB addr=0x7f1142992000 $ ulimit -v 512000 $ ./mmaptest # fails to mmap() 512 MiB due to ulimit mmap(): Cannot allocate memory Best regards, Vladis Dronov | Red Hat, Inc. | Product Security Engineer ----- Original Message ----- From: cve-assign@...re.org To: vdronov@...hat.com Cc: cve-assign@...re.org, oss-security@...ts.openwall.com Sent: Wednesday, March 2, 2016 6:00:31 PM Subject: [oss-security] Re: CVE request -- linux kernel: pipe: limit the per-user amount of pages allocated in pipes -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=759c01142a5d0f364a462346168a56de28a80f52 > The result is an OOM condition and oom-killer is not able to help > much, as the memory for the pipe data is a kernel memory and a memory > footprint of offensive processes is small. We feel that this should most likely have a CVE ID. The discussion outlines a realistic problem "it is possible for a single process to cause an OOM condition by filling large pipes with data that are never read. A typical process filling 4000 pipes with 1 MB of data will use 4 GB of memory" and the need for a CVE ID does not depend on the details of the solution approach. Also, there doesn't seem to be any general opposition to addressing the problem (e.g., see the https://lkml.org/lkml/2016/1/19/674 post). However, the commit indicates that there isn't a mandatory behavior change ("The limit are controlled by two new sysctls : pipe-user-pages-soft, and pipe-user-pages-hard. Both may be disabled by setting them to zero.") -- suggesting a possible interpretation as a design enhancement, not a vulnerability fix. Also, the discussion doesn't directly comment on whether the "filling large pipes" scenario has a security impact that is otherwise unavailable to the attacker, e.g., it doesn't discuss the difference between the attacker choosing to fill 4000 pipes and the attacker choosing to use mmap. Is there anyone who believes 759c01142a5d0f364a462346168a56de28a80f52 must not have a CVE ID? > The commit says: "Mitigates: CVE-2013-4312 (Linux 2.0+)" Regardless of any answers to the above question, it is not going to be useful to use CVE-2013-4312 to refer to 759c01142a5d0f364a462346168a56de28a80f52. - -- CVE assignment team, MITRE CVE Numbering Authority M/S M300 202 Burlington Road, Bedford, MA 01730 USA [ PGP key available through http://cve.mitre.org/cve/request_id.html ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJW1xqUAAoJEL54rhJi8gl5sFcQAJjoPTO/xZL8sFOwfACRAXWD ycctDOyagiKIwnf9qyqSw18CTTskA2bRJTlhGywu3XnEKq/yAyYfj2+bNQ5OdvmT sQT+JTASckJIDnjqXefSxHZMbBTPOITyEZ52cZSRF8NvWyos1GUBxZRXE6Y1Nrx3 VF1pNDpbbjJtPpwQ81atxUInE9TDeG0o7BUcX5wP/Q4yIdjU1nZ2MdrYYK4Sn2H2 2/DECleX8EG8oUrPGxm64OXxmAOxB3E3Vigc0LC6OBindvU6VhjyeKzuKduu4W+m 6GkIllgEzkBGlwqXTmLvbeB+TpnHU3w6ZdnAynmJHwV+AmivFOPHsJhOXlrAKz7S KRIkAgeSHOjqK6rg3V3+/az33v9yzl3dQGEmZYs3d/bX94A2q8Z/ECNOfMHk0uH3 BbveT32coxxqOjAT4NrOVfWsQtiz2B2hSQek8URYYNuONKI/Qmc6Dk/lnTK5K4jO l3/tAqNM/avKbp6Q5rJ+JBZX/nH7x05bNx2klPVB1yZyBn6F+RbJYauQMerEcMUa ChSVYfUi7+k9ogqk/7/b8EhJiLK92CmBfsUFTIvuI+UUq0fQNMKGXvmYYJHHKOi/ DJcKAIid0FLbXXi1YsCrFJu2NrvS0UiKOUeF/D0rVdm3emYGTIWbQOkvuDAsUs7e 8mWQWhBXp+LU6fTUHdZi =pIDG -----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.