> On 22 Sep 2020, at 11:31, Sandro Gauci <san...@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. Thank you, a very good post. Maybe something that we want to come back to as a community in an open brainstorm meeting rather than a formal meeting - to see what comes out.
Cheers, /O > > 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/ > > <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: >> 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 >>> <mailto: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 >>> <mailto: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 >>>> <mailto: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 <mailto:sobo...@sippysoft.com>> >>>> Sent: Wednesday, September 2, 2020 9:15 PM >>>> To: Henning Westerholt <h...@skalatan.de <mailto:h...@skalatan.de>> >>>> Cc: Daniel-Constantin Mierla <mico...@gmail.com >>>> <mailto:mico...@gmail.com>>; yufei....@gmail.com >>>> <mailto:yufei....@gmail.com>; Olle E. Johansson <o...@edvina.net >>>> <mailto:o...@edvina.net>>; Gerry | Rigatta <gjacob...@rigatta.com >>>> <mailto:gjacob...@rigatta.com>>; Kamailio (SER) - Users Mailing List >>>> <sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>>; >>>> jbro...@signalogic.com <mailto: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 >>>> <mailto: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 >>>> <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@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@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@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@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
