All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlad Yasevich <vladislav.yasevich@hp.com>
To: Wei Yongjun <yjwei@cn.fujitsu.com>
Cc: lksctp-developers@lists.sourceforge.net, netdev@vger.kernel.org,
	David Miller <davem@davemloft.net>
Subject: Re: [PATCH] SCTP: Fix possible memory leak while process INIT chunk with AUTH paramters
Date: Tue, 25 Mar 2008 09:03:52 -0400	[thread overview]
Message-ID: <47E8F838.1010906@hp.com> (raw)
In-Reply-To: <47E31A76.6060903@cn.fujitsu.com>

Wei Yongjun wrote:
> Hi Vlad:
> 
> Vlad Yasevich wrote:
>> Hi Wei
>>
>> Wei Yongjun wrote:
>>> While endpoint received INIT/INIT-ACK chunk with AUTH parameters, 
>>> such as RANDOM, HMAC_ALGO, CHUNKS parameter, if those parameters 
>>> appear more then once, memory for store those parameters will be 
>>> malloc more then once and not free.
>>>
>>
>> All these parameters must be included only once in the packet.
> 
> RFC 4890 has the following text:
> 
>   The RANDOM parameter MUST be included once in the INIT or INIT-ACK
>   chunk, if the sender wants to send or receive authenticated chunks,
>   to provide a 32-byte Random Number.  For 32-byte Random Numbers, the
>   Padding is empty.
> 
> 
> It said *MUST be included once*, not *only once*, is this right?

I guess it depends on the interpretation.  If they are allowed more then
once, then which parameter should be used.  The spec leaves that undefined.

Undefined behavior on a security extension is usually treated as an exploit.
That's my take on this.

> 
>>
>> If these things are included more then once, we should either ABORT or
>> completely ignore the packet.  I haven't decided which one makes more
>> sense yet.
>>
>> If someone when to the trouble of violating the protocol, we should not
>> establish the association with them.
> 
> I think do ABORT with protocol violation is better, do the same thing as 
> the other protocol violation case do.

Yes.

-vlad
> 
> Wei Yongjun
> 


      reply	other threads:[~2008-03-25 13:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-20  7:09 [PATCH] SCTP: Fix possible memory leak while process INIT chunk with AUTH paramters Wei Yongjun
2008-03-20 12:24 ` Vlad Yasevich
2008-03-21  2:16   ` Wei Yongjun
2008-03-25 13:03     ` Vlad Yasevich [this message]

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=47E8F838.1010906@hp.com \
    --to=vladislav.yasevich@hp.com \
    --cc=davem@davemloft.net \
    --cc=lksctp-developers@lists.sourceforge.net \
    --cc=netdev@vger.kernel.org \
    --cc=yjwei@cn.fujitsu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.