[sr-dev] Security vulnerability handling

Daniel-Constantin Mierla miconda at gmail.com
Thu Feb 5 17:46:19 CET 2015


On 05/02/15 17:02, Olle E. Johansson wrote:
> 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. 
I haven't disputed how you (want to be) called it.

Because you mentioned the situation in your email, I just added
clarifications so everyone is becoming properly aware if it is affected
or not.

Cheers,
Daniel

-- 
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




More information about the sr-dev mailing list