Hi Olle, the page you are pointing to does not contain any Kamailio security advisories. What is needed is a timeline of advisories so one can and understand whether one's system is vulnerable, and what the vulnerability is - like this: https://www.asterisk.org/downloads/security-advisories/ <https://www.asterisk.org/downloads/security-advisories/> As mentioned it would be also helpful to label github issues so one can filter for security issues.
Best Gerry > On 22 Sep 2020, at 15:26, Olle E. Johansson <o...@edvina.net> wrote: > > > >> On 22 Sep 2020, at 13:30, Gerry | Rigatta <gjacob...@rigatta.com >> <mailto:gjacob...@rigatta.com>> wrote: >> >> 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 >> <https://www.cvedetails.com/vulnerability-list/vendor_id-15820/Kamailio.html> >> as the most comprehensive source. However it lacks this latest header bug. >> > https://www.kamailio.org/wiki/security/policy > <https://www.kamailio.org/wiki/security/policy> > > Maybe we should make it easier to find from the home page as you did not find > it. > > /O >> 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/ >> <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 >> <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 <mico...@gmail.com >>> <mailto:mico...@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.html >>> <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-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> >>> -- >>> 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@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 > > _______________________________________________ > 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