Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1575465 - (CVE-2018-1124) CVE-2018-1124 procps-ng, procps: Integer overflows leading to heap overflow in file2strvec
CVE-2018-1124 procps-ng, procps: Integer overflows leading to heap overflow i...
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
high Severity high
: ---
: ---
Assigned To: Red Hat Product Security
impact=important,public=20180517:1700...
: Security
Depends On: 1579642 1577019 1577020 1577021 1577022 1579641 1602221 1602998
Blocks: 1575455
  Show dependency treegraph
 
Reported: 2018-05-06 22:01 EDT by Doran Moppert
Modified: 2018-07-26 09:15 EDT (History)
11 users (show)

See Also:
Fixed In Version: procps-ng 3.3.15
Doc Type: If docs needed, set a value
Doc Text:
Multiple integer overflows leading to heap corruption flaws were discovered in file2strvec(). These vulnerabilities can 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).
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-06-04 05:18:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
jrybar: needinfo-


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2018:1700 None None None 2018-05-23 11:52 EDT
Red Hat Product Errata RHSA-2018:1777 None None None 2018-05-31 09:59 EDT
Red Hat Product Errata RHSA-2018:1820 None None None 2018-06-11 02:56 EDT
Red Hat Product Errata RHSA-2018:2267 None None None 2018-07-26 08:02 EDT
Red Hat Product Errata RHSA-2018:2268 None None None 2018-07-26 09:15 EDT

  None (edit)
Description Doran Moppert 2018-05-06 22:01:12 EDT
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)
Comment 6 Doran Moppert 2018-05-08 02:06:29 EDT
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.
Comment 7 Albert Cahalan 2018-05-08 14:13:15 EDT
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.
Comment 10 Kamil Dudka 2018-05-11 12:53 EDT
Created attachment 1435048 [details]
el6 backport of the fix

Could you please review the attached el6 backport of the fix?
Comment 22 Adam Mariš 2018-05-16 07:16:47 EDT
Acknowledgments:

Name: Qualys Research Labs
Comment 23 Vladis Dronov 2018-05-16 08:31:24 EDT
(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.
Comment 26 Doran Moppert 2018-05-18 01:13:48 EDT
Public via: http://seclists.org/oss-sec/2018/q2/122
Comment 27 Doran Moppert 2018-05-18 01:13:55 EDT
External References:

https://www.qualys.com/2018/05/17/procps-ng-audit-report-advisory.txt
Comment 28 Doran Moppert 2018-05-18 01:14:23 EDT
Created procps-ng tracking bugs for this issue:

Affects: fedora-all [bug 1579642]
Comment 31 Albert Cahalan 2018-05-18 05:15:32 EDT
(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.
Comment 36 errata-xmlrpc 2018-05-23 11:52:27 EDT
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
Comment 38 errata-xmlrpc 2018-05-31 09:59:26 EDT
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
Comment 39 errata-xmlrpc 2018-06-11 02:56:49 EDT
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
Comment 45 errata-xmlrpc 2018-07-26 08:02:23 EDT
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
Comment 46 errata-xmlrpc 2018-07-26 09:15:07 EDT
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

Note You need to log in before you can comment on or make changes to this bug.