Bug 1575465 (CVE-2018-1124) - CVE-2018-1124 procps-ng, procps: Integer overflows leading to heap overflow in file2strvec
Summary: CVE-2018-1124 procps-ng, procps: Integer overflows leading to heap overflow i...
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2018-1124
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1577019 1577020 1577021 1577022 1579641 1579642 1602221 1602998 1719424 1724854
Blocks: 1575455
TreeView+ depends on / blocked
 
Reported: 2018-05-07 02:01 UTC by Doran Moppert
Modified: 2019-09-29 14:38 UTC (History)
11 users (show)

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).
Clone Of:
Environment:
Last Closed: 2018-06-04 09:18:54 UTC
jrybar: needinfo-


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2018:1700 None None None 2018-05-23 15:52:34 UTC
Red Hat Product Errata RHSA-2018:1777 None None None 2018-05-31 13:59:32 UTC
Red Hat Product Errata RHSA-2018:1820 None None None 2018-06-11 06:56:56 UTC
Red Hat Product Errata RHSA-2018:2267 None None None 2018-07-26 12:02:30 UTC
Red Hat Product Errata RHSA-2018:2268 None None None 2018-07-26 13:15:15 UTC
Red Hat Product Errata RHSA-2019:1944 None None None 2019-07-30 09:08:29 UTC
Red Hat Product Errata RHSA-2019:2401 None None None 2019-08-07 11:35:52 UTC

Description Doran Moppert 2018-05-07 02:01:12 UTC
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 06:06:29 UTC
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 18:13:15 UTC
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 16:53:43 UTC
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 11:16:47 UTC
Acknowledgments:

Name: Qualys Research Labs

Comment 23 Vladis Dronov 2018-05-16 12:31:24 UTC
(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 05:13:48 UTC
Public via: http://seclists.org/oss-sec/2018/q2/122

Comment 27 Doran Moppert 2018-05-18 05:13:55 UTC
External References:

https://www.qualys.com/2018/05/17/procps-ng-audit-report-advisory.txt

Comment 28 Doran Moppert 2018-05-18 05:14:23 UTC
Created procps-ng tracking bugs for this issue:

Affects: fedora-all [bug 1579642]

Comment 31 Albert Cahalan 2018-05-18 09:15:32 UTC
(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 15:52:27 UTC
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 13:59:26 UTC
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 06:56:49 UTC
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 12:02:23 UTC
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 13:15:07 UTC
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

Comment 49 errata-xmlrpc 2019-07-30 09:08:28 UTC
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

Comment 50 errata-xmlrpc 2019-08-07 11:35:51 UTC
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


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