[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
