[asterisk-dev] [Code Review]: Ensure chan_sip rejects encrypted streams without crypto info

[opticron]

> On Nov. 26, 2012, 3:03 p.m., Mark Michelson wrote:
> > The actual process_sdp() changes are good. Ship it!
> > 
> > The thing that bothers me a bit is that we don't always check the return value of process_sdp(). The times we check are when processing INVITEs, 200 OKs, and ACKs. For any early media responses, we will not check the return value of process_sdp() (we will sometimes set a variable, but then we don't actually do anything with it). What implications might this have if someone sends an early media SDP with SAVP audio but no encryption attributes?

Cases to consider: 180, 182, 183, and any other 1xx message which is handled by the generic case and has SDP

This change will not affect the processing of these messages during initial invites (just catches it a little earlier).

This will affect these messages in reinvites where SAVP had previously been negotiated.  The result in these cases is no audio (SRTP unprotect failures) when the key has changed but was not included or working audio when the key has not changed and was not included, assuming that the media endpoint address was not modified by the malformed SDP in question.


- opticron


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2204/#review7434
-----------------------------------------------------------


On Nov. 21, 2012, 2:28 p.m., opticron wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2204/
> -----------------------------------------------------------
> 
> (Updated Nov. 21, 2012, 2:28 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> Prior to this patch, Asterisk would accept encrypted media streams (RTP/SAVP audio and video) without ensuring cryptographic keys were present on reinvites.  This patch ensures that the incoming SDP is consistent with RFC4568 as far as having a crypto attribute present for any SAVP streams.
> 
> 
> This addresses bug AST-1040.
>     https://issues.asterisk.org/jira/browse/AST-1040
> 
> 
> Diffs
> -----
> 
>   branches/1.8/channels/chan_sip.c 376388 
> 
> Diff: https://reviewboard.asterisk.org/r/2204/diff
> 
> 
> Testing
> -------
> 
> Tested with a broken (snom 320 with 7.3.30 firmware) and non-broken (CSIPSimple on Android) client to ensure reinvites were rejected when malformed.
> 
> 
> Thanks,
> 
> opticron
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20121127/8e2326f2/attachment.htm>