public inbox for linux-sctp@vger.kernel.org
 help / color / mirror / Atom feed
From: Joshua Kinard <kumba@gentoo.org>
To: Daniel Borkmann <dborkman@redhat.com>, davem@davemloft.net
Cc: linux-sctp@vger.kernel.org, netdev@vger.kernel.org,
	Vlad Yasevich <vyasevich@gmail.com>
Subject: Re: [PATCH net 1/3] net: sctp: fix skb_over_panic when receiving malformed ASCONF chunks
Date: Fri, 10 Oct 2014 10:04:23 +0000	[thread overview]
Message-ID: <5437AF27.2030506@gentoo.org> (raw)
In-Reply-To: <1412888133-833-2-git-send-email-dborkman@redhat.com>

On 10/09/2014 16:55, Daniel Borkmann wrote:
> Commit 6f4c618ddb0 ("SCTP : Add paramters validity check for
> ASCONF chunk") added basic verification of ASCONF chunks, however,
> it is still possible to remotely crash a server by sending a
> special crafted ASCONF chunk, even up to pre 2.6.12 kernels:
> 
> skb_over_panic: text:ffffffffa01ea1c3 len:31056 put:30768
>  head:ffff88011bd81800 data:ffff88011bd81800 tail:0x7950
>  end:0x440 dev:<NULL>
>  ------------[ cut here ]------------
> kernel BUG at net/core/skbuff.c:129!
> [...]
> Call Trace:
>  <IRQ>
>  [<ffffffff8144fb1c>] skb_put+0x5c/0x70
>  [<ffffffffa01ea1c3>] sctp_addto_chunk+0x63/0xd0 [sctp]
[snip]
> 
> This can be triggered e.g., through a simple scripted nmap
> connection scan injecting the chunk after the handshake, for
> example, ...
> 
>   -------------- INIT[ASCONF; ASCONF_ACK] ------------->
>   <----------- INIT-ACK[ASCONF; ASCONF_ACK] ------------
>   -------------------- COOKIE-ECHO -------------------->
>   <-------------------- COOKIE-ACK ---------------------
>   ------------------ ASCONF; UNKNOWN ------------------>
> 
> ... where ASCONF chunk of length 280 contains 2 parameters ...
> 
>   1) Add IP address parameter (param length: 16)
>   2) Add/del IP address parameter (param length: 255)
> 
> ... followed by an UNKNOWN chunk of e.g. 4 bytes. Here, the
> Address Parameter in the ASCONF chunk is even missing, too.
> This is just an example and similarly-crafted ASCONF chunks
> could be used just as well.

If I am reading correctly, this crash can only be triggered by actually getting
through the SCTP handshake, then sending this specially-crafted ASCONF chunk?
Meaning a blind nmap scan using this tactic against a random netblock wouldn't
just randomly knock servers offline?  This would seem to reduce the attack
surface a quite bit by requiring the remote endpoint to actually respond.

Is there a CVE # for this?

Thanks!,

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

  reply	other threads:[~2014-10-10 10:04 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-09 20:55 [PATCH net 0/3] SCTP fixes Daniel Borkmann
2014-10-09 20:55 ` [PATCH net 1/3] net: sctp: fix skb_over_panic when receiving malformed ASCONF chunks Daniel Borkmann
2014-10-10 10:04   ` Joshua Kinard [this message]
2014-10-10 22:06     ` Daniel Borkmann
2014-10-10 14:48   ` Neil Horman
2014-10-09 20:55 ` [PATCH net 2/3] net: sctp: fix panic on duplicate " Daniel Borkmann
2014-10-10 15:39   ` Neil Horman
2014-10-10 22:02     ` Daniel Borkmann
2014-10-12  1:42       ` Neil Horman
2014-10-12  7:15         ` Vladislav Yasevich
2014-10-12 23:25         ` Daniel Borkmann
2014-10-15  2:58           ` Neil Horman
2014-10-15 23:13             ` Daniel Borkmann
2014-10-15  7:51           ` Vlad Yasevich
2014-10-09 20:55 ` [PATCH net 3/3] net: sctp: fix remote memory pressure from excessive queueing Daniel Borkmann
2014-10-14 16:46 ` [PATCH net 0/3] SCTP fixes David Miller
2014-10-15  3:06   ` Neil Horman
2014-10-15  4:21     ` David Miller
2014-10-15 20:20       ` Neil Horman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5437AF27.2030506@gentoo.org \
    --to=kumba@gentoo.org \
    --cc=davem@davemloft.net \
    --cc=dborkman@redhat.com \
    --cc=linux-sctp@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=vyasevich@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox