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

Christer Holmberg <christer.holmberg@ericsson.com> Thu, 09 December 2010 06:59 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5F443A6A31 for <sipcore@core3.amsl.com>; Wed, 8 Dec 2010 22:59:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.154
X-Spam-Level:
X-Spam-Status: No, score=-6.154 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcMmq55VjRNT for <sipcore@core3.amsl.com>; Wed, 8 Dec 2010 22:59:00 -0800 (PST)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id CC9403A6A2E for <sipcore@ietf.org>; Wed, 8 Dec 2010 22:58:59 -0800 (PST)
X-AuditID: c1b4fb39-b7bd2ae000001d22-21-4d007e8b05b9
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 7A.C1.07458.B8E700D4; Thu, 9 Dec 2010 08:00:28 +0100 (CET)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 9 Dec 2010 08:00:27 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: 'Robert Sparks' <rjsparks@nostrum.com>
Date: Thu, 9 Dec 2010 08:00:27 +0100
Thread-Topic: [sipcore] Security issue in -keep-08
Thread-Index: AcuXEJZKjXW2ou41Qy+5A99K62MWPQAA95ggABZ/6SA=
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05850315547D@ESESSCMS0356.eemea.ericsson.se>
References: <9D7CD9CF-4E47-41D1-8D01-F98808851223@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05850307D840@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585030B1833@ESESSCMS0356.eemea.ericsson.se>, <02688FBA-D5B4-403E-944E-FB9245936F36@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A058502C718A9@ESESSCMS0356.eemea.ericsson.se> <AAC3B2AF-41D1-4EDC-AB90-89874182B856@nostrum.com> <72CAC7D1-E370-4D2E-AF68-8FBFE0469641@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A058502B84087@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058502B84087@ESESSCMS0356.eemea.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: SIPCORE <sipcore@ietf.org>
Subject: Re: [sipcore] Security issue in -keep-08
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Dec 2010 06:59:01 -0000

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: sipcore-bounces@ietf.org 
> [mailto:sipcore-bounces@ietf.org] 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:rjsparks@nostrum.com]
> 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: sipcore-bounces@ietf.org
> >>>> [mailto:sipcore-bounces@ietf.org] 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:rjsparks@nostrum.com]
> >>>>> 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
> >>>> sipcore@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/sipcore
> >>> 
> > 
> > _______________________________________________
> > sipcore mailing list
> > sipcore@ietf.org
> > https://www.ietf.org/mailman/listinfo/sipcore
> 
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>