On Tue, 22 Sep 2020, at 12:55 PM, Daniel-Constantin Mierla 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".
Sorry about the misquote. I have clarified that part of the post. If anyone feels that I misquoted them, feel free to reach out directly on list, offlist or over matrix/wire etc (sandrogauci). > 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-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 >> > -- Daniel-Constantin Mierla -- www.asipto.com > www.twitter.com/miconda -- www.linkedin.com/in/miconda Funding: https://www.paypal.me/dcmierla
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
