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

Reply via email to