[sr-dev] Security vulnerability handling

Thu Feb 5 17:02:20 CET 2015

On 05 Feb 2015, at 16:55, Daniel-Constantin Mierla <miconda at gmail.com> wrote:

> 
> On 05/02/15 16:12, Olle E. Johansson wrote:
>> On 05 Feb 2015, at 16:08, Daniel-Constantin Mierla <miconda at gmail.com> wrote:
>> 
>>> On 05/02/15 16:03, Olle E. Johansson wrote:
>>>> On 05 Feb 2015, at 15:54, Daniel-Constantin Mierla <miconda at gmail.com> wrote:
>>>> 
>>>>> Just to give proper details about the issue ...
>>>>> 
>>>>> It is not that any 30x response sent by anyone was causing a crash, only
>>>>> those received in a transaction and handled via get_redirects(), with an
>>>>> empty URI in Contact header. That means an authenticated/trusted
>>>>> endpoint has to be involved in such a call. The code causing it is also
>>>>> quite old (might be close to 10 years now).
>>>> How was authentication involved? I could repeat the crash without auth.
>>> Are you allowing traffic on your server without any authentication or
>>> trust relationship? The get_redirects() is allowed only in a failure
>>> route, so there is a transaction, thus the INVITE was trusted somehow
>>> and relayed.
>>> 
>>> If you have an open relay server, then I guess security is not your concern.
>>> 
>> You are describing most of the SIP trunking platforms out there. There's
>> authentication for calling to the sip trunk from the customer, but not
>> when the SIP trunk calls the customer. Many customers have phones that
>> generate 302 for voicemail/DND/call forwarding. 
>> 
>> Hosted PBX services will have to support 302 from a customer - in most
>> cases without authentication.
> If you sent the INVITE to your customer's phone, then eventually the
> address is from location, which was stored there because you
> authenticated the REGISTER. So the equipment that can send the 30x is
> somehow trusted.
> 
>> 
>> You can be cynical about it, but that's life out there regardless - our users.
>> We should warn them about this.
> 
> I haven't said it was not an issue that didn't need attention, given
> that I looked at it pretty much immediately, with a fix is short time.
> 
> My message was to clarify when such situation occurs and it cannot occur
> unless it is a trusted call (again, I don't care about cases of open
> relays, they don't give any security anyhow).
> 
> The situation can be triggered only if a trusted party (authenticated
> user or trusted peer) is involved. That to make clear that it is not the
> case when someone just sends a crafted 302 to your proxy and crashes it.
> Either the INVITE is initiated by a trusted user/peer or lands to a
> trusted user/peer.
> 
> Your message was just mentioning the 302 in general, with no details of
> the specific situation with a transaction and get_redirects(), which can
> be misinterpreted as anyone can send a crafted 302 to any kind of
> configuration.
> 
Ok, get your point. But I don't buy the trust part - anyone I send an
INVITE to can send a 302, regardless what kind of relationship I have.

Now, I would normally not allow anyone to send me a 302, but we can't
guarantee that all Kamailio users have the same policy.

> Now each can look at security issues by how critical are and rank their
> importance by that -- this one requires a prior relationship with the
> service provider, it cannot be done by anyone out there.
It won't make the service provider more happy to know that any customer
can crash his system. ..

I still think this is a security issue and should be handled as such. 

/O
> 
> Cheers,
> Daniel
>> 
>> /O
>> 
>> 
>>> Cheers,
>>> Daniel
>>> 
>>>> If someone is using this function towards phones and the phone responds with a 
>>>> crafted 302 - which is now in the wild - we will crash if this module
>>>> and function is used - regardless of how old the code is. A crash is a crash.
>>>> In a situation a message sent as a response will cause Kamailio to crash.
>>>> That's no good.
>>>> 
>>>> Even if we hope that there is no one using it this way, we can't know.
>>>> In my view, this is clearly a security issue.
>>>> 
>>>>> So there is no risk of being hit by malicious/unknown attackers from the
>>>>> wild.
>>>> I don't agree with this assesment.  We are allowed to have different views :-)
>>>> 
>>>> Note that this is propably the first time I have seen this kind of issue with
>>>> Kamailio... 
>>>> 
>>>> I propably have to add conflict resolution to my security vulnerability proposal ;-)
>>>> 
>>>> /O
>>>>> Cheers,
>>>>> Daniel
>>>>> 
>>>>> On 05/02/15 15:36, Olle E. Johansson wrote:
>>>>>> Friends,
>>>>>> 
>>>>>> I think today's issue with a 302 message sent to kamailio causing a crash is a security issue. It was dealt with swiftly, but I feel we need a more formal procedure for handling it, producing patches and releasing security information.
>>>>>> 
>>>>>> I've made a quick proposal that outlines a few simple things and policys. We should make it too complex, but I feel it's important for all our users that a project has some procedure on how to handle situations like this.
>>>>>> 
>>>>>> Please check the proposal in the dev meeting agenda and let's discuss it in the dev meeting.
>>>>>> 
>>>>>> http://www.kamailio.org/wiki/devel/irc-meetings/2015a
>>>>>> 
>>>>>> /O
>>>>>> _______________________________________________
>>>>>> sr-dev mailing list
>>>>>> sr-dev at lists.sip-router.org
>>>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>>>> -- 
>>>>> Daniel-Constantin Mierla
>>>>> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>>>> Kamailio World Conference, May 27-29, 2015
>>>>> Berlin, Germany - http://www.kamailioworld.com
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> sr-dev mailing list
>>>>> sr-dev at lists.sip-router.org
>>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>> -- 
>>> Daniel-Constantin Mierla
>>> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>> Kamailio World Conference, May 27-29, 2015
>>> Berlin, Germany - http://www.kamailioworld.com
>>> 
> 
> -- 
> Daniel-Constantin Mierla
> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
> Kamailio World Conference, May 27-29, 2015
> Berlin, Germany - http://www.kamailioworld.com
> 