netdev - Re: [PATCH] SCTP: Fix possible memory leak while process INIT chunk with AUTH paramters

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 25 Mar 2008 09:03:52 -0400
From:	Vlad Yasevich <vladislav.yasevich@...com>
To:	Wei Yongjun <yjwei@...fujitsu.com>
Cc:	lksctp-developers@...ts.sourceforge.net, netdev@...r.kernel.org,
	David Miller <davem@...emloft.net>
Subject: Re: [PATCH] SCTP: Fix possible memory leak while process INIT chunk
 with AUTH paramters

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
> 

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html