5 Feb
2015
5 Feb
'15
4:36 p.m.
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
5 Feb
5 Feb
4:54 p.m.
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).
So there is no risk of being hit by malicious/unknown attackers from the
wild.
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
5:03 p.m.
On 05 Feb 2015, at 15:54, Daniel-Constantin Mierla <miconda(a)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.
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
5:08 p.m.
On 05/02/15 16:03, Olle E. Johansson wrote:
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.
Cheers,
Daniel
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.
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.
--
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
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
5:12 p.m.
On 05 Feb 2015, at 16:08, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote:
On 05/02/15 16:03, Olle E. Johansson wrote:
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.
You can be cynical about it, but that's life out there regardless - our users.
We should warn them about this.
/O
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. 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.
--
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
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
5:55 p.m.
On 05/02/15 16:12, Olle E. Johansson wrote:
On 05 Feb 2015, at 16:08, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
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.
On 05/02/15 16:03, Olle E. Johansson wrote:
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. 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.
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.
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.
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(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
> --
> 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
6:02 p.m.
On 05 Feb 2015, at 16:55, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote:
On 05/02/15 16:12, Olle E. Johansson wrote:
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.
On 05 Feb 2015, at 16:08, Daniel-Constantin
Mierla <miconda(a)gmail.com> wrote:
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.
On 05/02/15 16:03, Olle E. Johansson wrote:
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. On 05 Feb 2015, at 15:54, Daniel-Constantin
Mierla <miconda(a)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 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.
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(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
> --
> 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
6:46 p.m.
On 05/02/15 17:02, Olle E. Johansson wrote:
On 05 Feb 2015, at 16:55, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
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
On 05/02/15 16:12, Olle E. Johansson wrote:
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.
On 05 Feb 2015, at 16:08, Daniel-Constantin
Mierla <miconda(a)gmail.com> wrote:
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.
On 05/02/15 16:03, Olle E. Johansson wrote:
> On 05 Feb 2015, at 15:54, Daniel-Constantin Mierla <miconda(a)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. 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.
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. 
5:16 p.m.
Hi
On 05/02/15 16:08, Daniel-Constantin Mierla wrote:
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.
Javi
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.
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
5:58 p.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
5:04 p.m.
Hello
in the operators/carriers world, the 302 messages might be coming from
equipments beyond the immediate trusted endpoint. This one might can
just relay the reponse without processing it, there are really broken
systems out there. So I agree with Olle in dealing these issues in a
specific way. I was hesitant to raise the issue in a public list; but at
the same time I thought it was a good idea to make everybody aware of a
potential risk. Having a specific group devoted to security issues looks
like the way to go. I am happy to help with testing or any other thing.
Regards
Javi
On 05/02/15 15:54, Daniel-Constantin Mierla 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).
So there is no risk of being hit by malicious/unknown attackers from the
wild.
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
3582
days inactive
3582
days old
10 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Javi Gallart -
Olle E. Johansson