linux/net/sctp
Daniel Borkmann 26b87c7881 net: sctp: fix remote memory pressure from excessive queueing
This scenario is not limited to ASCONF, just taken as one
example triggering the issue. When receiving ASCONF probes
in the form of ...

  -------------- INIT[ASCONF; ASCONF_ACK] ------------->
  <----------- INIT-ACK[ASCONF; ASCONF_ACK] ------------
  -------------------- COOKIE-ECHO -------------------->
  <-------------------- COOKIE-ACK ---------------------
  ---- ASCONF_a; [ASCONF_b; ...; ASCONF_n;] JUNK ------>
  [...]
  ---- ASCONF_m; [ASCONF_o; ...; ASCONF_z;] JUNK ------>

... where ASCONF_a, ASCONF_b, ..., ASCONF_z are good-formed
ASCONFs and have increasing serial numbers, we process such
ASCONF chunk(s) marked with !end_of_packet and !singleton,
since we have not yet reached the SCTP packet end. SCTP does
only do verification on a chunk by chunk basis, as an SCTP
packet is nothing more than just a container of a stream of
chunks which it eats up one by one.

We could run into the case that we receive a packet with a
malformed tail, above marked as trailing JUNK. All previous
chunks are here goodformed, so the stack will eat up all
previous chunks up to this point. In case JUNK does not fit
into a chunk header and there are no more other chunks in
the input queue, or in case JUNK contains a garbage chunk
header, but the encoded chunk length would exceed the skb
tail, or we came here from an entirely different scenario
and the chunk has pdiscard=1 mark (without having had a flush
point), it will happen, that we will excessively queue up
the association's output queue (a correct final chunk may
then turn it into a response flood when flushing the
queue ;)): I ran a simple script with incremental ASCONF
serial numbers and could see the server side consuming
excessive amount of RAM [before/after: up to 2GB and more].

The issue at heart is that the chunk train basically ends
with !end_of_packet and !singleton markers and since commit
2e3216cd54 ("sctp: Follow security requirement of responding
with 1 packet") therefore preventing an output queue flush
point in sctp_do_sm() -> sctp_cmd_interpreter() on the input
chunk (chunk = event_arg) even though local_cork is set,
but its precedence has changed since then. In the normal
case, the last chunk with end_of_packet=1 would trigger the
queue flush to accommodate possible outgoing bundling.

In the input queue, sctp_inq_pop() seems to do the right thing
in terms of discarding invalid chunks. So, above JUNK will
not enter the state machine and instead be released and exit
the sctp_assoc_bh_rcv() chunk processing loop. It's simply
the flush point being missing at loop exit. Adding a try-flush
approach on the output queue might not work as the underlying
infrastructure might be long gone at this point due to the
side-effect interpreter run.

One possibility, albeit a bit of a kludge, would be to defer
invalid chunk freeing into the state machine in order to
possibly trigger packet discards and thus indirectly a queue
flush on error. It would surely be better to discard chunks
as in the current, perhaps better controlled environment, but
going back and forth, it's simply architecturally not possible.
I tried various trailing JUNK attack cases and it seems to
look good now.

Joint work with Vlad Yasevich.

Fixes: 2e3216cd54 ("sctp: Follow security requirement of responding with 1 packet")
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-10-14 12:46:22 -04:00
..
associola.c net: sctp: fix panic on duplicate ASCONF chunks 2014-10-14 12:46:22 -04:00
auth.c net: sctp: cache auth_enable per endpoint 2014-04-18 18:32:00 -04:00
bind_addr.c sctp: Fix FSF address in file headers 2013-12-06 12:37:56 -05:00
chunk.c sctp: fix checkpatch errors with space required or prohibited 2013-12-26 13:47:47 -05:00
debug.c sctp: Fix FSF address in file headers 2013-12-06 12:37:56 -05:00
endpointola.c net: sctp: migrate most recently used transport to ktime 2014-06-11 12:23:17 -07:00
input.c sctp: Change sctp to implement csum_levels 2014-08-29 20:41:11 -07:00
inqueue.c net: sctp: fix remote memory pressure from excessive queueing 2014-10-14 12:46:22 -04:00
ipv6.c sctp: Fixup v4mapped behaviour to comply with Sock API 2014-07-31 21:49:06 -07:00
Kconfig net: sctp: get rid of SCTP_DBG_TSNS entirely 2013-07-02 00:08:03 -07:00
Makefile net: sctp: Inline the functions from command.c 2014-07-08 14:38:48 -07:00
objcnt.c sctp: fix checkpatch errors with (foo*)|foo * bar|foo* bar 2013-12-26 13:47:47 -05:00
output.c Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net 2014-08-05 18:46:26 -07:00
outqueue.c net: sctp: Rename SCTP_XMIT_NAGLE_DELAY to SCTP_XMIT_DELAY 2014-07-22 13:32:11 -07:00
primitive.c sctp: Fix FSF address in file headers 2013-12-06 12:37:56 -05:00
probe.c sctp: loading sctp when load sctp_probe 2013-12-16 20:04:27 -05:00
proc.c snmp: fix some left over of snmp stats 2014-05-14 15:33:47 -04:00
protocol.c net/ipv4: bind ip_nonlocal_bind to current netns 2014-09-09 11:27:09 -07:00
sm_make_chunk.c net: sctp: fix skb_over_panic when receiving malformed ASCONF chunks 2014-10-14 12:46:22 -04:00
sm_sideeffect.c net: sctp: Don't transition to PF state when transport has exhausted 'Path.Max.Retrans'. 2014-04-27 23:41:14 -04:00
sm_statefuns.c net: sctp: fix remote memory pressure from excessive queueing 2014-10-14 12:46:22 -04:00
sm_statetable.c sctp: fix checkpatch errors with indent 2013-12-26 13:47:48 -05:00
socket.c net: sctp: fix ABI mismatch through sctp_assoc_to_state helper 2014-08-29 20:31:08 -07:00
ssnmap.c sctp: Fix FSF address in file headers 2013-12-06 12:37:56 -05:00
sysctl.c net: sctp: only warn in proc_sctp_do_alpha_beta if write 2014-07-02 18:44:07 -07:00
transport.c sctp: Fixup v4mapped behaviour to comply with Sock API 2014-07-31 21:49:06 -07:00
tsnmap.c sctp: Fix FSF address in file headers 2013-12-06 12:37:56 -05:00
ulpevent.c sctp: Fixup v4mapped behaviour to comply with Sock API 2014-07-31 21:49:06 -07:00
ulpqueue.c sctp: add support for busy polling to sctp protocol 2014-04-20 18:18:55 -04:00