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 <mailto:sobomax@sippysoft.com>>
Sent: Wednesday, September 2, 2020 9:15 PM
To: Henning Westerholt <hw(a)skalatan.de <mailto:hw@skalatan.de>>
Cc: Daniel-Constantin Mierla <miconda(a)gmail.com <mailto:miconda@gmail.com>>;
yufei.tao(a)gmail.com <mailto:yufei.tao@gmail.com>; Olle E. Johansson
<oej(a)edvina.net <mailto:oej@edvina.net>>; Gerry | Rigatta
<gjacobsen(a)rigatta.com <mailto:gjacobsen@rigatta.com>>; Kamailio (SER) - Users
Mailing List <sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>>; jbrower(a)signalogic.com
<mailto:jbrower@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
<mailto:hw@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
<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 <http://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