After 20 years in voip, my 2 cents on this, if you succeed in creating a
voip system where the security of the whole relies on the ability to remove
(or only keep specific) custom sip headers, you will wake up one morning
realizing a bunch of people in Palestine made a gazillion calls over your
system to expensive destinations, bringing you to or over the edge of
bankruptcy.
Security should be multilayered, one header sneaking through should not
give any big problems.
risk, I think. It's a bit more than low as you can do
more than just get
some info, but it's not high, as you would need to have many other factors
going wrong to get to a successful exploit.
Op do 3 sep. 2020 om 09:18 schreef Olle E. Johansson <oej(a)edvina.net>et>:
One thought - we may have to separate security
vulnerability reporting
from security advisory documents. I think in some cases, where a common use
of a product can lead to issues (but it is not clearly a bug that cause
crashes in our code) we may have to send out an advisory and publish it in
the same way. The problem with that is where the border is between just
doing stupid things like taking SQL statements from SIP headers and issues
like this that are harder to catch.
We had a long and hard discussion about this in the Asterisk project many
years ago - a very common dialplan construct (that was documented in many
places) was indeed very dangerous. It wasn’t any code in asterisk that
caused the issue, just a common dialplan construct that existed in many,
many production systems. In the end, if I remember correctly, the project
issued an advisory and added a README about it.
Maybe that’s a way forward.
/O
On 2 Sep 2020, at 21:25, Henning Westerholt <hw(a)skalatan.de> wrote:
Hello Maxim,
have a look to the first sentence:
“A security vulnerability is (for example) when a user of Kamailio can
cause Kamailio to crash or lock up by sending messages to the server
process.”
So there is some limitation regarding vulnerability criticality defined in
there. But of course (as I already mentioned), it might be improved to e.g.
use CVSS scoring instead.
Cheers,
Henning
*From:* Maxim Sobolev <sobomax(a)sippysoft.com>
*Sent:* Wednesday, September 2, 2020 9:15 PM
*To:* Henning Westerholt <hw(a)skalatan.de>
*Cc:* Daniel-Constantin Mierla <miconda(a)gmail.com>om>; yufei.tao(a)gmail.com;
Olle E. Johansson <oej(a)edvina.net>et>; Gerry | Rigatta <gjacobsen(a)rigatta.com>om>;
Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>rg>;
jbrower(a)signalogic.com
*Subject:* Re: [SR-Users] Kamailio vulnerable to header smuggling
possible due to bypass of remove_hf
On Wed, Sep 2, 2020 at 11:30 AM Henning Westerholt <hw(a)skalatan.de> wrote:
Hello Maxim,
thank you for the clarification, appreciated.
No worries, hope to have a civilized discussion.
Just one clarification, my comment regarding the advisory from 2018 was
not meant as advertisement etc..
Point taken, I dramatized of course to underline my point.
One suggestion to objectify the whole discussion, there exists a
well-known and accepted metric for vulnerabilities: CVSS [1]
If I calculate the CVSS score for this issue, it results in a medium level
with score 5.8. But this is of course again (at least somewhat) influenced
from my point of view to this bug.
Some projects have a policy to only do a security announcement for
vulnerabilities with score high and critical. For Kamailio this is not yet
defined in a detailed way, due to the size of the project and other factors.
So, If people in this discussion (or other people on the list) are
interested in improving the project security processes – this wiki page
with the current process might be a good starting point:
https://www.kamailio.org/wiki/security/policy
Please suggest your improvements to the existing process (preferable in a
new discussion thread) on the sr-dev list. If you want to do it in private,
feel free contact the management list.
Well, first suggestion after having read it: to start actually following
what's documented before any improvements are made. ;-) The policy says
plain and simple (quote):
Publishing security vulnerabilities
Kamailio will publish security vulnerabilities, including an CVE ID, on
the kamailio-business mailing list, sr-dev, sr-users as well as related
lists. The advisories will also be published on the
kamailio.org web site.
CVE entries should be created for vulnerabilities in the core and major
modules, for rarely used modules this is not necessary. If there are
several security issues together in one release, they should be announced
together.
I might be missing something obvious, but there is no "if" or "maybe"
or
"it depends". Any module that has been 18 years with the project qualifies
to be a "major module" to me...
-Max
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users