22 Sep
2020
22 Sep
'20
1:55 p.m.
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.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:
1. Introduction
2. A bit of background before diving in
3. Claim: this issue does not affect many organisations
4. Claim: custom headers are only known to internal users
5. Claim: if it’s an 18 year old bug, it can’t have been high risk
6. Claim: this should have been found if people were doing proper testing
7. Claim: infrequent advisories = project is not serious about security
8. Claim: limited number of advisories = project is more secure
9. Claim: if you’re serious about security, monitor the mailing lists
10. Claim: security experts should decide what is a security vulnerability
11. Discussion: when should the project publish an advisory?
12. Discussion: educational security role
13. 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:
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
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
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
_______________________________________________
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 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