1 Dec
2011
1 Dec
'11
2 p.m.
1 dec 2011 kl. 12:54 skrev Daniel-Constantin Mierla:
On 12/1/11 12:44 PM, Olle E. Johansson wrote:
I think there are clear definitions here we can copy. I'll take a look.
/O
1 dec 2011 kl. 11:43 skrev Daniel-Constantin
Mierla:
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...
On 11/29/11 9:28 PM, Olle E. Johansson wrote:
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. 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).