Multiple integer overflows leading to heap corruption in file2strvec() lead to privilege escalation for a local attacker who can create entries in procfs by starting processes, which will lead to crashes or arbitrary code execution in proc utilities run by other users (eg pgrep, pkill, pidof, w)
See also bug 1575853: > CVE-2018-1126 procps-ng, procps: incorrect integer size in proc/alloc.* leading to truncation / integer overflow issues. CVE-2018-1126 was identified by Qualys as a precondition for the way they exploited CVE-2018-1124. Correcting that issue will prevent other flaws of this kind being introduced by future changes.
Generally, the /proc filesystem should not supply /proc/*/cmdline or /proc/*/environ files that are nearly 1024 times as large as it allows processes to be created with. If procps is to tolerate that, then the proper solution is to bail on such large files. They are corrupted and should not be displayed. Attempting to display a couple gigabytes or more would allow a denial of service attack. Input truncation at the display width would additionally be productive. This helps avoid the problem of a million /proc/*/cmdline files which are each a megabyte, leading to a terabyte allocated in the libproc library. To be clear: procps should not generally support /proc/*/cmdline or /proc/*/environ files exceeding INT_MAX in size. This causes denial of service for an important set of tools.
Created attachment 1435048 [details] el6 backport of the fix Could you please review the attached el6 backport of the fix?
Acknowledgments: Name: Qualys Research Labs
(In reply to Albert Cahalan from comment #7) > Generally, the /proc filesystem should not supply /proc/*/cmdline or > /proc/*/environ files that are nearly 1024 times as large as it allows > processes to be created with. /proc/*/cmdline and /proc/*/environ content is not provided by procfs, but just parts of the "*" process memory mapped into these files. processes are free to do with their own memory whatever they want, including increasing their cmdline arguments space and environment to gigabytes. it is up to users of these files (here: procps utils) but not the kernel to handle such corner cases.
Public via: http://seclists.org/oss-sec/2018/q2/122
External References: https://www.qualys.com/2018/05/17/procps-ng-audit-report-advisory.txt
Created procps-ng tracking bugs for this issue: Affects: fedora-all [bug 1579642]
(In reply to Vladis Dronov from comment #23) > (In reply to Albert Cahalan from comment #7) > > Generally, the /proc filesystem should not supply /proc/*/cmdline or > > /proc/*/environ files that are nearly 1024 times as large as it allows > > processes to be created with. > > /proc/*/cmdline and /proc/*/environ content is not provided by procfs, but > just parts of the "*" process memory mapped into these files. processes are > free to do with their own memory whatever they want, including increasing > their cmdline arguments space and environment to gigabytes. it is up to > users of these files (here: procps utils) but not the kernel to handle such > corner cases. I'm well aware of how it works and the implications, being both a professional security researcher and a former procps maintainer. (maintained procps from about 1996 to 2006, wrote the ps program, and even wrote a bit of the /proc filesystem code) You're getting my response late because somebody took away my access to the bug, which was not at all sensible. (already knew, and am an expert) The /proc/ files are all provided by the /proc filesystem. Yes, yes, some get pulled out of process memory in some way, but this is 100% under the control of the kernel. If I remember right, at one point the kernel limited the size in /proc to 4096 bytes, despite the fact that it supported 131072 when starting processes. There really isn't good reason for the kernel to let /proc expose more bytes than would be allowed for starting a process.
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2018:1700 https://access.redhat.com/errata/RHSA-2018:1700
This issue has been addressed in the following products: Red Hat Enterprise Linux 6 Via RHSA-2018:1777 https://access.redhat.com/errata/RHSA-2018:1777
This issue has been addressed in the following products: Red Hat Virtualization 4 for RHEL-7 Via RHSA-2018:1820 https://access.redhat.com/errata/RHSA-2018:1820
This issue has been addressed in the following products: Red Hat Enterprise Linux 6.7 Extended Update Support Via RHSA-2018:2267 https://access.redhat.com/errata/RHSA-2018:2267
This issue has been addressed in the following products: Red Hat Enterprise Linux 6.6 Advanced Update Support Red Hat Enterprise Linux 6.6 Telco Extended Update Support Via RHSA-2018:2268 https://access.redhat.com/errata/RHSA-2018:2268
This issue has been addressed in the following products: Red Hat Enterprise Linux 7.4 Extended Update Support Via RHSA-2019:1944 https://access.redhat.com/errata/RHSA-2019:1944
This issue has been addressed in the following products: Red Hat Enterprise Linux 7.3 Advanced Update Support Red Hat Enterprise Linux 7.3 Update Services for SAP Solutions Red Hat Enterprise Linux 7.3 Telco Extended Update Support Via RHSA-2019:2401 https://access.redhat.com/errata/RHSA-2019:2401