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.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 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 >
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
