Re: [sipcore] Security issue in -keep-08

[Christer Holmberg <[e-mail]>]

Hi Robert,

Thanks for reviewing the document!

I guess the attack you describe could also happen in Outbound, if someone inserts an "ob" parameter in the Path header of the proxy adjacent to the UA, and that proxy does not check its Path header before forwarding the response to the UA.

Having said that, I guess a way to protect against this attack could be to say that an entity MUST stop sending STUN messages if it doesn't receive a response to them.

Regards,

Christer




 

> -----Original Message-----
> From: Robert Sparks [mailto:[e-mail]] 
> Sent: 23. marraskuuta 2010 22:00
> To: SIPCORE
> Cc: Christer Holmberg
> Subject: Security issue in -keep-08
> 
> I believe there is a serious problem with the recommendations 
> in the Security Considerations section in keep-08 where it 
> discusses having downstream elements change the keep parameter.
> 
> Consider this scenario. A user agent implementing this 
> specification sends a request that goes through two proxies 
> before it arrives at its destination. The first proxy does 
> not know about this specification. The second proxy does, and 
> chooses to attempt to maliciously affect the relationship 
> between UA1 and P1 as suggested in these security considerations.
> 
> View the following flow in a fixed-width font:
> 
> UA1                  P1               P2    UA2
>  |                   |                |      | 
>  | INVITE            |                |      |
>  | Via: UA;keep      | INVITE         |      |
>  |------------------>| Via: P1        |      | 
>  |                   | Via: UA;keep   |      | 
>  |                   |--------------->|      |
>  |                   |                |----->| 
>  |                   |                | 200  |
>  |                   | 200            |<-----|
>  |                   | Via: P1        |      |
>  | 200               | Via: UA;keep=1 |      |
>  | Via: UA;keep=1    |<---------------|      |
>  |<------------------|                |      | 
>  |                   |                |      | 
> 
> 
> Since P1 doesn't support this specification, it does not know 
> to look at "it's" Via to see if some downstream element has 
> modified what it would have put in the keep parameter value - 
> the recommendation in the current draft does not mitigate 
> this attack at all. If the hop between UA1 and P1 is UDP, 
> this may result in STUN being send towards P1's SIP listening 
> port with P1 not expecting (or being able to deal with) it.
> 
> This is a general problem with attempting to use Via 
> parameters to indicate support for extensions. A similar 
> problem exists for ;rport, and for ;lr. However, if a 
> downstream element abused those parameters, signaling is 
> guaranteed to fail. This proposed parameter has a different 
> property - this abuse may only result in extra traffic for 
> someone else.
> 
> I don't think this document is the right place to solve the 
> general problem, but this discussion needs to be rewritten to 
> be clearer about the problem and the lack of any current way 
> to mitigate it.
> 
> RjS