[Bug network/20112] sunrpc: stack (frame) overflow in Sun RPC clntudp_call (CVE-2016-4429)

[Bug network/20112] sunrpc: stack (frame) overflow in Sun RPC clntudp_call (CVE-2016-4429)

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20112

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com

--- Comment #16 from Florian Weimer <fweimer at redhat dot com> ---
Created attachment 12624
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12624&action=edit
tst-rpc-udp-client.c

I looked at this again.

On really old kernels (I tried kernel-2.6.32-754.29.2.el6.x86_64), I could not
get looping behavior 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.

With kernel-3.10.0-327.el7.x86_64 and kernel-5.6.11-200.fc31.x86_64, I see
looping behavior 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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug network/20112] sunrpc: stack (frame) overflow in Sun RPC clntudp_call (CVE-2016-4429)

[huzaifas at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20112

Huzaifa Sidhpurwala <huzaifas at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |huzaifas at redhat dot com

--- Comment #17 from Huzaifa Sidhpurwala <huzaifas at redhat dot com> ---
As per upstream " it's extremely unlikely that real-world applications are
impacted by this."

Florian can you please explain/comment on this.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug network/20112] sunrpc: stack (frame) overflow in Sun RPC clntudp_call (CVE-2016-4429)

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20112

--- Comment #18 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Huzaifa Sidhpurwala from comment #17)
> As per upstream " it's extremely unlikely that real-world applications are
> impacted by this."
> 
> Florian can you please explain/comment on this.

In order to trigger a denial-of-service condition, an attacker would have to
send a stream of appropriate ICMP messages at high rate. It is likely that an
attacker who is able to do that can just flood the network directly, degrading
the service in a similar fashion than a crash would (although perhaps with less
permanence).

The main concern regarding this bug seems to be whether it allows remote code
execution. This is theoretically possible if the alloca call allows skipping
the guard page. For this to be possible, several factors need to align:

* glibc must have been built without -fstack-clash-protection.

* The application must be multi-threaded. For a single-threaded application,
the guard page supplied by kernel pages is so large that it is not possible to
skip over it using packets received from the network.

* The application must generate UDP RPC packets which are larger than the guard
page (minus 200 bytes). This is rather unusual because the guard page is
typically 4K, and the network MTU is 1500 bytes or less, and applications
usually try to keep UDP packet size small, to avoid dealing with
fragmentation-related issues.

Please let me know if you have further questions.

-- 
You are receiving this mail because:
You are on the CC list for the bug.