[tracker] Assignee added: Crash if t_release() is executed after t_relay_to(), when this last returns -1
29 Nov
2011
29 Nov
'11
6:57 p.m.
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
29 Nov
9:28 p.m.
New subject: [tracker] Assignee added: Crash if t_release() is executed after t_relay_to(), when this last returns -1
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?
/O
9:52 p.m.
New subject: [tracker] Assignee added: Crash if t_release() is executed after t_relay_to(), when this last returns -1
2011/11/29 Olle E. Johansson <oej(a)edvina.net>et>:
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().
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
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,
10:13 p.m.
New subject: [tracker] Assignee added: Crash if t_release() is executed after t_relay_to(), when this last returns -1
29 nov 2011 kl. 21:52 skrev Iñaki Baz Castillo:
2011/11/29 Olle E. Johansson <oej(a)edvina.net>et>:
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().
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
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, 
1 Dec
1 Dec
11:43 a.m.
New subject: [tracker] Assignee added: Crash if t_release() is executed after t_relay_to(), when this last returns -1
On 11/29/11 9:28 PM, Olle E. Johansson wrote:
29 nov 2011 kl. 18:57 skrev sip-router:
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
--
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
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?
12:44 p.m.
New subject: [tracker] Assignee added: Crash if t_release() is executed after t_relay_to(), when this last returns -1
1 dec 2011 kl. 11:43 skrev Daniel-Constantin Mierla:
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.
We need to learn as we move along.
/O
29 nov 2011 kl. 18:57 skrev sip-router:
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). 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?
12:54 p.m.
New subject: [tracker] Assignee added: Crash if t_release() is executed after t_relay_to(), when this last returns -1
On 12/1/11 12:44 PM, Olle E. Johansson wrote:
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...
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
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:
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). 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?
1 p.m.
New subject: [tracker] Assignee added: Crash if t_release() is executed after t_relay_to(), when this last returns -1
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). 
12:44 p.m.
New subject: [tracker] Assignee added: Crash if t_release() is executed after t_relay_to(), when this last returns -1
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
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).
12:58 p.m.
New subject: [tracker] Assignee added: Crash if t_release() is executed after t_relay_to(), when this last returns -1
On 12/1/11 12:44 PM, Henning Westerholt wrote:
On Thursday 01 December 2011, Daniel-Constantin Mierla
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
--
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
[..]
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. 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).
1:15 p.m.
New subject: [tracker] Assignee added: Crash if t_release() is executed after t_relay_to(), when this last returns -1
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
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.
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
4529
days inactive
4531
days old
10 comments
5 participants
participants (5)
-
Daniel-Constantin Mierla -
Henning Westerholt -
Iñaki Baz Castillo -
Olle E. Johansson -
sip-router