Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 1575852 - (CVE-2018-1125) CVE-2018-1125 procps-ng, procps: stack buffer overflow in pgrep
CVE-2018-1125 procps-ng, procps: stack buffer overflow in pgrep
Status: NEW
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
impact=low,public=20180517:1700,repor...
: Security
Depends On: 1577027 1577028 1579635 1579636
Blocks: 1575455
  Show dependency treegraph
 
Reported: 2018-05-08 01:57 EDT by Doran Moppert
Modified: 2018-06-04 20:44 EDT (History)
6 users (show)

See Also:
Fixed In Version: procps-ng 3.3.15
Doc Type: If docs needed, set a value
Doc Text:
If an argument longer than INT_MAX bytes is given to pgrep, "int bytes" could wrap around back to a large positive int (rather than approaching zero), leading to a stack buffer overflow via strncat().
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Doran Moppert 2018-05-08 01:57:17 EDT
If an argument longer than INT_MAX bytes is given to pgrep, "int bytes" could wrap around back to a large positive int (rather than approaching zero), leading to a stack buffer overflow.

This vulnerability is mitigated by FORTIFY, as it involves strncat() to a stack-allocated string. When pgrep is compiled with FORTIFY (as on Red Hat Enterprise Linux and Fedora), the impact is limited to a crash.
Comment 2 Albert Cahalan 2018-05-09 02:03:51 EDT
The bug description appears to be incorrect. This is not about an argument being given to pgrep. This is about an argument given to a process that is under examination by pgrep.

Due to the use of an int in the allocator, the string length can never be large enough to case the integer to wrap back to being positive.

Supporting strings in excess of a couple megabytes is undesirable because this would put pgrep at risk of running out of memory, possibly via the OOM killer.
Comment 3 Doran Moppert 2018-05-10 22:42:28 EDT
> This is not about an argument being given to pgrep. This is about an argument given to a process that is under examination by pgrep.

Thanks, this is correct.  Again, this should probably ultimately be addressed in the kernel, but hardening procps in the meantime might be desirable.

On the other hand, it seems that FORTIFY effectively mitigates and per commentary in the patch:

> Fortunately, every distribution that we checked compiles its procps utilities with FORTIFY, and the fortified strncat() detects and aborts the buffer overflow before it occurs.
Comment 5 Adam Mariš 2018-05-16 07:19:13 EDT
Acknowledgments:

Name: Qualys Research Labs
Comment 6 Doran Moppert 2018-05-18 01:13:29 EDT
Public via: http://seclists.org/oss-sec/2018/q2/122
Comment 7 Doran Moppert 2018-05-18 01:13:36 EDT
External References:

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

Affects: fedora-all [bug 1579635]

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