[SR-Users] Kamailio vulnerable to header smuggling possible due to bypass of remove_hf
Maxim Sobolev
sobomax at sippysoft.com
Tue Sep 22 18:33:09 CEST 2020
Hey Sandro, thanks for putting this together. I frankly have been a little
puzzled and a bit disappointed by the lack of response from you on that
topic. But then Daniel mentioned some "special relationship" he has with
you, so I just wrote it off to old-good cronyism. I am glad that I was
wrong on that matter.
I won't beat this dead horse too much again, just to reply to *many* here
who said "Kamailio community has no time/resources to deal with this
stuff". From my vantage point of view the amount of time Kamailio community
as a whole spent on "debunking header smuggling as a real security threat"
would probably be enough to create 5 security advisories in a better
structured project. Whether or not any lessons have been learned and
improvements made we will see the next time.
With that being said I'd probably go back to my usual read-mostly mode and
wish everyone a good and productive week!
-Max
On Tue, Sep 22, 2020 at 2:34 AM Sandro Gauci <sandro at enablesecurity.com>
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-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:
>
> 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.moere at 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 at 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 at 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 at sippysoft.com>
> *Sent:* Wednesday, September 2, 2020 9:15 PM
> *To:* Henning Westerholt <hw at skalatan.de>
> *Cc:* Daniel-Constantin Mierla <miconda at gmail.com>; yufei.tao at gmail.com;
> Olle E. Johansson <oej at edvina.net>; Gerry | Rigatta <gjacobsen at rigatta.com>;
> Kamailio (SER) - Users Mailing List <sr-users at lists.kamailio.org>;
> jbrower at 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 at 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 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 at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200922/45bdaaa9/attachment.htm>
More information about the sr-users
mailing list