22 Sep
2020
22 Sep
'20
2:30 p.m.
Hi Daniel,
your frustration is understandable and I hope you excuse a further comment. What is
missing, IMVHO, is a central point of reference for all Kamailio security issues. Googling
for “Kamailio security” reveals
https://www.cvedetails.com/vulnerability-list/vendor_id-15820/Kamailio.html as the most
comprehensive source. However it lacks this latest header bug.
My suggestion would be to create a special “Security Advisories” page on the kamailio
website which points to security news, so that Google indexes that page. As for example
Asterisk has https://www.asterisk.org/downloads/security-advisories/
And create on github an extra “security” label so one can filter for that.
https://github.com/kamailio/kamailio/labels
And then point from the above mentioned “Security Advisories” page to a filtered github
view.
Thanks for your great work on Kamailio. Its highly appreciated!
Best Gerry
On 22 Sep 2020, at 12:55, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
At least in my case you push out some inaccurate information. I never said my
"deployments were not affected since non-standard headers were not used".
Iirc, I only said that none of my deployments were affected by this issue -- respectively
quoting from my message: "None of my deployments were affected."
from:https://lists.kamailio.org/pipermail/sr-users/2020-September/110315.ht…
<https://lists.kamailio.org/pipermail/sr-users/2020-September/110315.html> . If I am
mistaken and you found another remark from me, just point to my message from where you got
that.
So, for further clarification: either non standard headers were used for non-security
related features (e.g., used for troubleshooting purposes) or the issue didn't affect
the deployments from different perspective (e.g., traffic was checked to be from a trusted
source).
And remember that the issue was not with remove_hf() function itself, like it is somehow
propagated by blog posts, but it was in the parser, so use of custom headers between two
kamailio was not affected if an edge proxy did something like:
remove_hf("X-H");
append_hf("X-H: abc\r\n");
And then, if next hop Kamailio was using $hdr(X-H), it will get "abc" (value
added by previous Kamailio), not what a bad actor would add as "X-H :
badvalue\r\n" sip header.
Then you listed two commits you consider there should have been security advisories
about. Have you analysed the code and found cases where security was affected, or is just
your opinion in based on the commit message and code patch?
First, I would love that one or many spend time to dissect commits and see their security
implication. I am more that happy when someone does it and let's everyone be aware of,
also to write and publish appropriate advisory.
Otherwise, for those two specific commits you listed, the one from Federico is a memory
leak, I haven't spent time on going deeper to find the specific cases, From header
should be parsed in SIP requests. My commit was done based on a static code analyzer and
again I was not spending time to see what implications are.
In general, in the code we work a lot with str structure (non-zero terminated char* and
len), many of the "safety" commits done lately were to silent static code
analysers, not meaning that it was a real issue found behind. Some can be, and here we
appreciate the time and effort of people like you to dissect them and make appropriate
advisories.
I would like people do verify what they write about what specific people (of course,
specially for my person) said before pushing out, and eventually validate a commit to fix
something has security impact, instead of just personal guessing, if the intention is to
help the project and not to create more confusion or other reactions for what so ever
reasons.
This should be my last comment on the thread, I do not want to spend any more time in
clarifying what people think I said or I did.
Cheers,
Daniel
On 22.09.20 11:31, Sandro Gauci wrote:
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-misconceptio…
<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
<https://keybase.io/sandrogauci>
Our blog: https://www.rtcsec.com
<https://www.rtcsec.com/>
Other points of contact: https://enablesecurity.com/#contact-us
<https://enablesecurity.com/#contact-us>
On Thu, 3 Sep 2020, at 10:34 AM, Olle E. Johansson wrote:
--
Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com/>
www.twitter.com/miconda <http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
Funding: https://www.paypal.me/dcmierla
<https://www.paypal.me/dcmierla>_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users> 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
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users> On 3 Sep 2020, at 10:14, davy van de moere
<davy.van.de.moere(a)gmail.com <mailto:davy.van.de.moere@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 <oej(a)edvina.net
<mailto:oej@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 <hw(a)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(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
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>