Bug 1337136 (CVE-2016-4429)
| Summary: | CVE-2016-4429 glibc: libtirpc: stack (frame) overflow in Sun RPC clntudp_call() | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Martin Prpič <mprpic> | ||||
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | unspecified | CC: | arjun.is, ashankar, codonell, dj, fweimer, hannsj_uhl, jakub, jlayton, law, mfabian, mnewsome, pfrankli, sardella, siddhesh, steved, yozone | ||||
| Target Milestone: | --- | Keywords: | Security | ||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | glibc 2.23.1 | Doc Type: | If docs needed, set a value | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2016-05-18 11:54:03 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | 1337140, 1337142 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
|
Description
Martin Prpič
2016-05-18 11:45:34 UTC
Acknowledgments: Name: Aldy Hernandez (Red Hat) Created libtirpc tracking bugs for this issue: Affects: fedora-all [bug 1337142] Created glibc tracking bugs for this issue: Affects: fedora-all [bug 1337140] Created attachment 1158765 [details] CVE-2016-4429 patch As per upstream: On Red Hat Enterprise Linux 6: No looping behaviour was observed because the error state on the socket appears to be sticky, so the second recvmsg (with MSG_DONTWAIT, after the one with MSG_ERRQUEUE) in clntudp_call does not fail with EWOULDBLOCK, and the function returns to the caller. Without the looping behavior, the alloca should be harmless for pretty much all applications because the size argument depends on the size of the generated (outgoing) UDP packet and will be well below default stack sizes. Therefore it is not affected by this flaw. On Red Hat Enterprise Linux 7: Looping behaviour was observed and segfaults with small stack sizes. -fstack-class-protection will turn this into a reliable crash (no code execution possible). Even without that build flag, this will not be exploitable in most cases because the application determines the alloca argument, based on the generated UDP packet (not the response). This will usually be smaller than a page. The maximum impact is therefore crash, there is no code execution involved. This issue was fixed in glibc-2.23.1, therefore Red Hat Enterprise Linux 8 is not affected by this flaw. Public reproducer is available at: https://sourceware.org/bugzilla/attachment.cgi?id=12624 Statement: Based on technical analysis of this flaw: On Red Hat Enterprise Linux 6: No looping behaviour was observed. Without the looping behavior, the alloca should be harmless for pretty much all applications because the size argument depends on the size of the generated (outgoing) UDP packet and will be well below default stack sizes. Therefore it is not affected by this flaw. On Red Hat Enterprise Linux 7: Looping behaviour was observed and segfaults with small stack sizes. -fstack-class-protection will turn this into a reliable crash (no code execution possible). Even without that build flag, this will not be exploitable in most cases because the application determines the alloca argument, based on the generated UDP packet (not the response). This will usually be smaller than a page. The maximum impact is therefore crash, there is no code execution involved. This issue was fixed in glibc-2.23.1, therefore Red Hat Enterprise Linux 8 is not affected by this flaw. |