[sr-dev] [tracker] Assignee added: Crash if t_release() is executed after t_relay_to(), when this last returns -1

[Daniel-Constantin Mierla]

On 12/1/11 12:44 PM, Olle E. Johansson wrote:
> 1 dec 2011 kl. 11:43 skrev Daniel-Constantin Mierla:
>
>>
>> On 11/29/11 9:28 PM, Olle E. Johansson wrote:
>>> 29 nov 2011 kl. 18:57 skrev sip-router:
>>>
>>>> THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
>>>>
>>>> A user has added themself to the list of users assigned to this task.
>>>>
>>>> FS#184 - Crash if t_release() is executed after t_relay_to(), when this last returns -1
>>>> User who did this - Iñaki Baz Castillo (ibc)
>>>> http://sip-router.org/tracker/index.php?do=details&task_id=184
>>>>
>>> Now this was caused by bad configuraiton, but if we have had or will have crashes based on incoming MI, RPC or SIP messages, we should have a routing for how to handle security fixes in Kamailio. When evaluating open source projects I always check the security procedures.
>>>
>>> Anyone interested in assisting in writing up a document about this we can publish on the web site and try to follow if we get such an issue? I think we can happily steal from other projects, so it should not be hard work.
>>>
>>> Anyone objecting to implementing a process for handling security incidents?
>> I have no objection in this regard, any contribution/managing process that will make usage of the project easier/more attractive for various people is welcome. The question will be who will take the work (e.g., reviewing, categorization, announcements to devels and community, ...).
>> Personally, I try not to make a difference between bugs, but just try to solve asap, with priority on how common use case is the situation rising the bug.
>>
>> Another question is categorizing 'security bugs' - in my understanding I consider such bugs when one can gain access to server or steal/compromise data from/on the server. Chasing situations are not in this category (IMO).
> That's one side of it. The other is when a message sent over the network can put the server in a bad state or crash it - a DOS attack oppurtunity.

Yes, it is, but this causes crashes even when it is not an intentional 
attack. Maybe a better phrasing would have been "security risk" bugs -- 
those that can compromise the privacy and integrity of data on the 
server. Otherwise, yes, they are bugs causing crashing and server 
unavailability -- the very common bugs we had and going to have many times.

I would rather use two categories:
- security - like access to server, data loss or unauthorized routing 
causing financial damages
- stability - like crashing, memory leaks, etc... (when they don't cause 
a security flaw)

Again, this is my perception and I know the limits of security depends 
on the point of view of each person. At the end, perhaps who is going to 
undertake the job will make the decision...

Cheers,
Daniel

-- 
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda