[tracker] Assignee added: Crash if t_release() is executed after t_relay_to(), when this last returns -1
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
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
29 nov 2011 kl. 18:57 skrev sip-router:
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?
/O
2011/11/29 Olle E. Johansson oej@edvina.net:
Hi Olle, do you mean that this crash is due to a bad configuration? maybe it does not make sense to call t_release() if t_relay() returned 0, but it should not crash. Also there are cases in which such decision is not so easy, for example when the script calls to t_newtran() before calling t_relay().
29 nov 2011 kl. 21:52 skrev Iñaki Baz Castillo:
Sorry, I think you misunderstand me. I agree that Kamailio should never crash. But there is no way a bad person can inject a bad configuration in your Kamailio over the network. Only yourself and your collegues should be able to inject this in the configuration, so it's not a security risc in my definition. Just a bad bug.
/O
On 11/29/11 9:28 PM, Olle E. Johansson wrote:
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).
Cheers
1 dec 2011 kl. 11:43 skrev Daniel-Constantin Mierla:
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.
We need to learn as we move along.
/O
On 12/1/11 12:44 PM, Olle E. Johansson wrote:
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
On Thursday 01 December 2011, Daniel-Constantin Mierla wrote:
Hi Daniel,
IMHO also certain denial of service attacks belongs to the "security bug" class. If somebody can easily bring my service down because of e.g. a crash during the processing of misformated (network) input then the availability of the service can be easily compromised.
Best regards,
Henning
On 12/1/11 12:44 PM, Henning Westerholt wrote:
Then flooding to fill the pipe will cause same kind of issue to availability of the service - a bug of the infrastructure.
As expressed in another email just sent, imo there are two categories here: stability and security
Cheers, Daniel
On Thursday 01 December 2011, Daniel-Constantin Mierla wrote:
Hi Daniel,
well, there is a difference between a "simple" DDOS attack, which of course can bring every service down given a big enough attackers bandwith, and a crash on single invalid (SIP, SSL setup etc..) message which is IMHO clearly a vulnerarbility.
The "classical" information security definition is CIA - confidentiality, integrity and availability. A break in due a software bug would be a breach of integrity, the discussed crash would affect the availability and e.g. a wrong usage of TLS that causes missing encryption in messages would be breach of the confidentially.
http://en.wikipedia.org/wiki/Information_security
But you're right, i guess the right person to make this descision is the one that will work on this stuff in the end..
Best regards,
Henning
-
Daniel-Constantin Mierla -
Henning Westerholt -
Iñaki Baz Castillo -
Olle E. Johansson -
sip-router