5 Feb
2015
5 Feb
'15
10:58 a.m.
Hello,
On 05/02/15 16:16, Javi Gallart wrote:
Hi
On 05/02/15 16:08, Daniel-Constantin Mierla wrote:
I agree it can happen and was fixed as discovered. But my message was a
clarification that if the deployment is not an open relay, then either
is not a malicious attack (but a broken equipment) or the attacker is
someone that has a relationship with the provider.
Hope all is clear now.
Cheers,
Daniel
On 05/02/15 16:03, Olle E. Johansson wrote:
No, we have a trust relationship and with everybody allowed to send
traffic to our platform; and thorough tests area done over test
equipment before exchanging traffic with them. But that's as far as we
can go; it they at some point misconfigure their platform and send us
back a malformed message there is not much we can do. On 05 Feb 2015, at 15:54, Daniel-Constantin
Mierla
<miconda(a)gmail.com> wrote:
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. 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.
Javi
--
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
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(a)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(a)lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev