On 05/02/15 16:12, Olle E. Johansson wrote:
On 05 Feb 2015, at 16:08, Daniel-Constantin Mierla miconda@gmail.com wrote:
On 05/02/15 16:03, Olle E. Johansson wrote:
On 05 Feb 2015, at 15:54, Daniel-Constantin Mierla miconda@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.
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@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@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