Bug 1575852 (CVE-2018-1125) - CVE-2018-1125 procps-ng, procps: stack buffer overflow in pgrep
Summary: CVE-2018-1125 procps-ng, procps: stack buffer overflow in pgrep
Status: NEW
Alias: CVE-2018-1125
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard: impact=low,public=20180517:1700,repor...
Keywords: Security
Depends On: 1577027 1577028 1579635 1579636
Blocks: 1575455
TreeView+ depends on / blocked
 
Reported: 2018-05-08 05:57 UTC by Doran Moppert
Modified: 2019-05-07 10:30 UTC (History)
6 users (show)

(edit)
If a process inspected by pgrep has an argument longer than INT_MAX bytes, "int bytes" could wrap around back to a large positive int (rather than approaching zero), leading to a stack buffer overflow via strncat().
Clone Of:
(edit)
Last Closed:


Attachments (Terms of Use)

Description Doran Moppert 2018-05-08 05:57:17 UTC
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 06:03:51 UTC
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-11 02:42:28 UTC
> 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 11:19:13 UTC
Acknowledgments:

Name: Qualys Research Labs

Comment 6 Doran Moppert 2018-05-18 05:13:29 UTC
Public via: http://seclists.org/oss-sec/2018/q2/122

Comment 7 Doran Moppert 2018-05-18 05:13:36 UTC
External References:

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

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

Affects: fedora-all [bug 1579635]

Comment 10 Doran Moppert 2019-03-18 01:39:09 UTC
Mitigation:

The procps suite on Red Hat Enterprise Linux is built with FORTIFY, which limits the impact of this stack overflow (and others like it) to a crash.


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