2 Sep
2020
2 Sep
'20
11:03 p.m.
Hello Maxim,
I think it would be a good idea to start a new thread to discuss process improvements, so
only a few comments.
As mentioned from Alex already, this is an open source project and not a company where the
CISO will check that all documented policies are done and checked to not lose the ISO
27001 certification (to exaggerate a bit as well).
The actions of the projects depend (among others) on the time, priorities and other
commitments of the individuals that do the work. And as already discussed extensively, I
think we as a project have handled this topic in a good way. Of course, there might be
always room for improvement, with the usual trade-offs.
If other companies are having some requirements that the project might not provide now,
they usually will pay somebody to develops it or develops it in-house. If companies are
having more requirement regarding certain processes, they usually allow a person on their
payroll spend a few days a month to work on this or again pay somebody to work on it. My
observation is that the contributions of companies in this Open Source project have been
so far more in the former area as the latter.
Best regards,
Henning
--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com<https://gilawa.com/>
From: Maxim Sobolev <sobomax(a)sippysoft.com>
Sent: Wednesday, September 2, 2020 9:38 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
Henning, well, sorry I respectfully disagree. The "for example" clause clearly
defines the following list as non-exclusive. What about let's say SQL injection
attacks? Are those "serious" enough? Or someone being able to bypass
authentication mechanisms? Any other 100500 potential ways to exploit complex code
systems?
In general it's safe to assume that what is and what isn't a security
vulnerability should be left to be decided by a security expert who reports it. It's
like when you go to the doctor for a checkup, you let him interpret your x-rays and other
analysis.
If Sandro in this particular case deems this issue as a "security
vulnerability", then the Kamailio team should just take it for granted. All IMHO of
course.
Adding score is fine, but that's a bit post-factum. IMHO you need a score when you
have too many vulnerabilities to report. Kamailio as we already established is not in this
category yet.
-Max
On Wed, Sep 2, 2020 at 12:25 PM Henning Westerholt
<hw@skalatan.de<mailto:hw@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@sippysoft.com<mailto:sobomax@sippysoft.com>>
Sent: Wednesday, September 2, 2020 9:15 PM
To: Henning Westerholt <hw@skalatan.de<mailto:hw@skalatan.de>>
Cc: Daniel-Constantin Mierla <miconda@gmail.com<mailto:miconda@gmail.com>>;
yufei.tao@gmail.com<mailto:yufei.tao@gmail.com>; Olle E. Johansson
<oej@edvina.net<mailto:oej@edvina.net>>; Gerry | Rigatta
<gjacobsen@rigatta.com<mailto:gjacobsen@rigatta.com>>; Kamailio (SER) - Users
Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>;
jbrower@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@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
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
--
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
Tel (Canada): +1-778-783-0474
Tel (Toll-Free): +1-855-747-7779
Fax: +1-866-857-6942
Web: http://www.sippysoft.com
MSN: sales@sippysoft.com<mailto:sales@sippysoft.com>
Skype: SippySoft