Bug 1337136 (CVE-2016-4429) - CVE-2016-4429 glibc: libtirpc: stack (frame) overflow in Sun RPC clntudp_call()
Summary: CVE-2016-4429 glibc: libtirpc: stack (frame) overflow in Sun RPC clntudp_call()
Keywords:
Status: CLOSED WONTFIX
Alias: CVE-2016-4429
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1337140 1337142
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-05-18 11:45 UTC by Martin Prpič
Modified: 2020-09-21 17:34 UTC (History)
16 users (show)

Fixed In Version: glibc 2.23.1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-05-18 11:54:03 UTC


Attachments (Terms of Use)
CVE-2016-4429 patch (946 bytes, text/plain)
2016-05-18 11:49 UTC, Martin Prpič
no flags Details


Links
System ID Priority Status Summary Last Updated
Sourceware 20112 P2 RESOLVED sunrpc: stack (frame) overflow in Sun RPC clntudp_call (CVE-2016-4429) 2020-09-21 17:33:19 UTC

Description Martin Prpič 2016-05-18 11:45:34 UTC
A stack frame overflow flaw was found in the glibc's clntudp_call(). A malicious server could use this flaw to flood a connecting client application with ICMP and UDP packets, triggering the stack overflow and resulting in a crash.

clntudp_call() contains an alloca call in a loop, which causes it to consume very large amounts of stack space.

The same faulty code is also present in the libtirpc library.

Comment 1 Martin Prpič 2016-05-18 11:45:49 UTC
Acknowledgments:

Name: Aldy Hernandez (Red Hat)

Comment 2 Martin Prpič 2016-05-18 11:47:47 UTC
Created libtirpc tracking bugs for this issue:

Affects: fedora-all [bug 1337142]

Comment 3 Martin Prpič 2016-05-18 11:47:56 UTC
Created glibc tracking bugs for this issue:

Affects: fedora-all [bug 1337140]

Comment 5 Martin Prpič 2016-05-18 11:49:36 UTC
Created attachment 1158765 [details]
CVE-2016-4429 patch

Comment 7 Huzaifa S. Sidhpurwala 2020-06-16 14:56:07 UTC
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.

Comment 8 Huzaifa S. Sidhpurwala 2020-06-16 14:57:35 UTC
Public reproducer is available at: https://sourceware.org/bugzilla/attachment.cgi?id=12624

Comment 9 Huzaifa S. Sidhpurwala 2020-06-16 15:07:56 UTC
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.


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