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

[Christer Holmberg <[e-mail]>]

Hi,

I am ok with the text proposed by Robert, and I intend to include it in a new version of the draft.

(Robert, you mentioned section 10 of -03, but I assume you meant -08?)

Regards,

Christer 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Christer Holmberg
> Sent: 8. joulukuuta 2010 22:15
> To: 'Robert Sparks'
> Cc: SIPCORE
> Subject: Re: [sipcore] Security issue in -keep-08
> 
> 
> Hi Robert,
> 
> Thanks for providing the text!
> 
> I will take a detailed look at it tomorrow, but after a first 
> read it looks ok.
> 
> Regards,
> 
> Christer 
> 
> -----Original Message-----
> From: Robert Sparks [mailto:[e-mail]]
> Sent: 8. joulukuuta 2010 21:46
> To: Robert Sparks
> Cc: Christer Holmberg; SIPCORE
> Subject: Re: [sipcore] Security issue in -keep-08
> 
> Here's a quick attempt at the text I said I'd suggest. Please 
> note it contains new normative requirements.
> This would replace the 3rd paragraph of section 10 of -03.
> 
> ---
> The behavior defined in Sections 4.3 and 4.4 require an 
> element using the mechanism defined in this document to place 
> a value in the "keep" parameter in the topmost Via header 
> field value of a response the element sends. They do not 
> instruct the element to place a value in a "keep" parameter 
> of any request it forwards. In particular, SIP proxies MUST 
> NOT place a value into the keep parameter of the topmost Via 
> header field value of a request it receives before forwarding 
> it. A SIP proxy implementing this specification SHOULD remove 
> any keep parameter values in any Via header field values 
> below the topmost one in responses it receives before forwarding them.
> 
> When requests are forwarded across multiple hops, it is 
> possible for a malicious downstream element to tamper with 
> the accrued values in the Via header field. The malicious 
> element could place a value, or change an existing value in a 
> "keep" parameter in any of the Via header field values, not 
> just the topmost value. A proxy implementation that simply 
> forwards responses by stripping the topmost Via header field 
> value and not inspecting the resulting new topmost Via header 
> field value risks being adversely affected by such a 
> malicious downstream element. In particular, such a proxy may 
> start receiving STUN requests if it blindly forwards a 
> response with a keep parameter with a value it did not create 
> in the topmost Via header field. To lower the chances of the 
> malicious element's actions having adverse affects on such 
> proxies, when an entity sends STUN keep-alives to an adjacent 
> downstream entity and does not receive a response to those 
> STUN messages, it MUST stop sending the  keep-alive requests 
> for the remaining duration of the dialog (if the sending of 
> keep-alives were negotiated for a dialog) or until the 
> sending of keep-alives is re-negotiated for the registration 
> (if the sending keep-alives were negotiated for a registration).
> 
> On Nov 29, 2010, at 2:32 PM, Robert Sparks wrote:
> 
> > 
> > On Nov 29, 2010, at 2:23 PM, Christer Holmberg wrote:
> > 
> >> Hi,
> >> 
> >>> I don't object to the direction this text is taking, but 
> it doesn't 
> >>> _prevent_ attacks. It only mitigates the damage, >and it 
> assumes the attacked element doesn't just break when it gets 
> the first STUN message on its SIP listening port.
> >> 
> >> Well, if it breaks from a single STUN mesage I think there 
> is going to be trouble sooner or later anyway, because 
> nothing prevents entities from sending STUN messages (or 
> whatever data) to the listening port even if keep support is 
> not indicated.
> > Of course, and it might break if something sends any other 
> protocol (or line noise) to it as well.
> > But, there's a difference between "things might break if 
> something sends an unrequested alien message" and "we'll 
> force the system to send what might be an alien message as a 
> matter of normal operation and hope things don't break"
> > 
> >> 
> >> I have no idea what I could write in order to prevent the 
> attack from happening.
> > 
> > As I indicated in my earlier note, I don't think we _can_ 
> prevent this 
> > attack with the current tools, and I don't think it's this 
> document's job to make a new tool to address it.
> > What the document can do is capture what we understand, documenting 
> > the risk. I'll suggest some text if someone else doesn't 
> beat me to it -  it will be later this week at the earliest for me.
> > 
> > RjS
> > 
> > 
> >> 
> >> Regards,
> >> 
> >> Christer
> >> 
> >> 
> >> 
> >> 
> >> On Nov 26, 2010, at 1:30 AM, Christer Holmberg wrote:
> >> 
> >>> 
> >>> Hi Robert,
> >>> 
> >>> I suggest adding the following new paragraph to the 
> security considerations section:
> >>> 
> >>> "In order to prevent attacks, when an entity sends STUN 
> keep-alives 
> >>> to an adjacent downstream entity that is not willing to 
> receive keep-alives (or does not support STUN), but for which 
> willingess to receive keep-alives has been inidicated by some 
> other downstream entity, if the sending entity does not 
> receive a response to any of the STUN keep-alive requests, it 
> MUST stop sending the keep-alive requests for the remaining 
> duration of the dialog (if the sending of keep-alives were 
> negotiated for a dialog) or until the sending of keep-alives 
> is re-negotiated for the registration (if the sending 
> keep-alives were negotiated for a registration). Further 
> actions taken by the sending entity is outside the scope of 
> this specification."
> >>> 
> >>> Regards,
> >>> 
> >>> Christer
> >>> 
> >>>> -----Original Message-----
> >>>> From: [e-mail]
> >>>> [mailto:[e-mail]] On Behalf Of Christer Holmberg
> >>>> Sent: 24. marraskuuta 2010 14:50
> >>>> To: Robert Sparks; SIPCORE
> >>>> Subject: Re: [sipcore] Security issue in -keep-08
> >>>> 
> >>>> 
> >>>> 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
> >>>> _______________________________________________
> >>>> sipcore mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/sipcore
> >>> 
> > 
> > _______________________________________________
> > sipcore mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sipcore
> 
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>