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

Robert Sparks <rjsparks@nostrum.com> Wed, 08 December 2010 19:44 UTC

Return-Path: <rjsparks@nostrum.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 23E2A3A6869 for <sipcore@core3.amsl.com>; Wed, 8 Dec 2010 11:44:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.862
X-Spam-Level:
X-Spam-Status: No, score=-101.862 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
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 aTBtOZcwOqos for <sipcore@core3.amsl.com>; Wed, 8 Dec 2010 11:44:54 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id A0D623A6823 for <sipcore@ietf.org>; Wed, 8 Dec 2010 11:44:53 -0800 (PST)
Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oB8JkH5B067835 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Dec 2010 13:46:18 -0600 (CST) (envelope-from rjsparks@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: Robert Sparks <rjsparks@nostrum.com>
In-Reply-To: <AAC3B2AF-41D1-4EDC-AB90-89874182B856@nostrum.com>
Date: Wed, 08 Dec 2010 13:46:17 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <72CAC7D1-E370-4D2E-AF68-8FBFE0469641@nostrum.com>
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>
To: Robert Sparks <rjsparks@nostrum.com>
X-Mailer: Apple Mail (2.1082)
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
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: Wed, 08 Dec 2010 19:44:56 -0000

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