[asterisk-dev] [Code Review] 2987: ARI: Don't leak information about implementation details

[Matt Jordan]

> On Nov. 7, 2013, 9:58 p.m., David Lee wrote:
> > branches/12/main/rtp_engine.c, lines 1839-1842
> > <https://reviewboard.asterisk.org/r/2987/diff/2/?file=48011#file48011line1839>
> >
> >     Just a guess, but I think you'd want to drop the RTCP report completely if the associated channel was filtered out by the sanitizer.
> 
> opticron wrote:
>     This will pass a NULL into the ast_json_pack causing it to fail and return NULL if the channel snapshot is sanitized away.

Yeah, I don't like relying on that behavior.

(1) It relies on ast_json_pack to properly handle a failure from its underlying function calls. That's brittle.

(2) It's *really* hard to tell that the behavior you described is what will occur here. That increases the maintenance burden of this code.

I agree with David: check the sanitizer result first and explicitly return NULL if you aren't supposed to return any data; otherwise, continue with the message formatting.


- Matt


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


On Nov. 11, 2013, 3:12 p.m., opticron wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2987/
> -----------------------------------------------------------
> 
> (Updated Nov. 11, 2013, 3:12 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-22744
>     https://issues.asterisk.org/jira/browse/ASTERISK-22744
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> This change prevents channels used as implementation details from leaking out to ARI. It does this by preventing creation of JSON blobs of channel snapshots created from those channels and sanitizing JSON blobs of bridge snapshots as they are created. This introduces a framework for excluding information from output targeted at Stasis applications on a consumer-by-consumer basis using channel sanitization callbacks which could be extended to bridges or endpoints if necessary.
> 
> This results in NULL inputs to ast_json_pack calls which generate unhelpful error messages, so that has been dealt with as well.
> 
> This also corrects a bug I noticed while investigating the issue where BridgeCreated events would not be created.
> 
> 
> Diffs
> -----
> 
>   branches/12/res/stasis/app.c 402347 
>   branches/12/res/res_stasis.c 402347 
>   branches/12/res/ari/resource_endpoints.c 402347 
>   branches/12/res/ari/resource_channels.c 402347 
>   branches/12/res/ari/resource_bridges.c 402347 
>   branches/12/main/stasis_message.c 402347 
>   branches/12/main/stasis_endpoints.c 402347 
>   branches/12/main/stasis_channels.c 402347 
>   branches/12/main/stasis_bridges.c 402347 
>   branches/12/main/rtp_engine.c 402347 
>   branches/12/main/json.c 402347 
>   branches/12/include/asterisk/stasis_endpoints.h 402347 
>   branches/12/include/asterisk/stasis_channels.h 402347 
>   branches/12/include/asterisk/stasis_bridges.h 402347 
>   branches/12/include/asterisk/stasis_app.h 402347 
>   branches/12/include/asterisk/stasis.h 402347 
> 
> Diff: https://reviewboard.asterisk.org/r/2987/diff/
> 
> 
> Testing
> -------
> 
> Manual testing with bridges and channels.
> 
> 
> Thanks,
> 
> opticron
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20131111/05aeec87/attachment-0001.html>