Sandro-
I think your blog post on Kamailio security is well organized and well
written. Thanks for your effort and time to both document and cover
several perspectives.
What I have seen in formalized open source -- e.g. groups run by Linux
Foundation -- is the community will form a security subcommittee,
which has some measure of independence. Typically a "Technical
Steering Committee" or similar, with elected members, will vet
proposals and settle on one, and then authorize the security
subcommittee to implement. Proposals typically include reporting
methods, rules and timeframes on publishing / updating advisories, and
keeping things up organized and up to date on a centralized website.
There may also be security review and sign-off on mods or bug fixes in
certain code areas. Something like Atlassian confluence, with Wiki
pages that can be updated at any time by both developers and users is
typical (it looks like the Kamailio wiki could be used). From what
I've seen, in larger, formalized open sources the general idea is to
be open and transparent about anything related to security --
proactive rather than reactive. It's reasonable to say that's because
sub groups working in one part of the community don't want to be
caught off guard by surprise vulnerabilities caused by another sub
group. They want to trust the larger community is looking out for them.
I'm not saying Kamailio needs to be, or should be, this formalized --
some of the LF groups are hundreds of membes wiwth dozens of active
projects -- but the "independent subcommittee" (or semi-independent)
concept might be something to consider.
-Jeff
Quoting Sandro Gauci <san...@enablesecurity.com>:
I know I am waking up an old debate by replying to this thread.
Deeply sorry :-)
Finally got around to writing up a blog post about this very
thread where I (think) I spared absolutely no one, not even myself.
My post is called "The great Kamailio security debate and some
misconceptions debunked" and can be read here:
https://www.rtcsec.com/2020/09/02-kamailio-security-debate-and-misconceptions/
The ToC:
* Introduction
* A bit of background before diving in
* Claim: this issue does not affect many organisations
* Claim: custom headers are only known to internal users
* Claim: if it’s an 18 year old bug, it can’t have been high risk
* Claim: this should have been found if people were doing proper testing
* Claim: infrequent advisories = project is not serious about security
* Claim: limited number of advisories = project is more secure
* Claim: if you’re serious about security, monitor the mailing lists
* Claim: security experts should decide what is a security vulnerability
* Discussion: when should the project publish an advisory?
* Discussion: educational security role
* Moving forward
Hope that it is at least interesting and perhaps even constructive!
Best wishes,
--
Sandro Gauci, CEO at Enable Security GmbH
Register of Companies: AG Charlottenburg HRB 173016 B
Company HQ: Pappelallee 78/79, 10437
Berlin, Germany
PGP/Encrypted comms: https://keybase.io/sandrogauci
Our blog: https://www.rtcsec.com
Other points of contact: https://enablesecurity.com/#contact-us
On Thu, 3 Sep 2020, at 10:34 AM, Olle E. Johansson wrote:
Well, you have defined one definitive line between being stupid and
following some current practise :-)
I like to think we as a project have an educational role as
well. In this case explaining the bug we had and what it can cause.
We should definitely add a warning along the lines you write too
- relying on headers alone is bad and not best current practise.
/O
On 3 Sep 2020, at 10:14, davy van de moere
<davy.van.de.mo...@gmail.com> wrote:
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.
From a security point of view, this could be
called a 'normal' security 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 <o...@edvina.net>:
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 <h...@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
<sobo...@sippysoft.com>
SENT: Wednesday, September 2, 2020 9:15 PM
TO: Henning Westerholt <h...@skalatan.de>
CC: Daniel-Constantin Mierla
<mico...@gmail.com>; yufei....@gmail.com; Olle E. Johansson
<o...@edvina.net>; Gerry | Rigatta <gjacob...@rigatta.com>;
Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org>; jbro...@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 <h...@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[1] 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@lists.kamailio.org___
___https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users___
_____________________________________________________
___Kamailio (SER) - Users Mailing List___
___sr-users@lists.kamailio.org___
___https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users___
_____________________________________________________
___Kamailio (SER) - Users Mailing List___
___sr-users@lists.kamailio.org___
___https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users___
Links:
------
[1] http://kamailio.org/
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
