[SR-Users] Kamailio vulnerable to header smuggling possible due to bypass of remove_hf

[Maxim Sobolev]

Henning, well, sorry I respectfully disagree. The "for example" clause
clearly defines the following list as non-exclusive. What about let's say
SQL injection attacks? Are those "serious" enough? Or someone being able to
bypass authentication mechanisms? Any other 100500 potential ways to
exploit complex code systems?

In general it's safe to assume that what is and what isn't a security
vulnerability should be left to be decided by a security expert who reports
it. It's like when you go to the doctor for a checkup, you let him
interpret your x-rays and other analysis.

If Sandro in this particular case deems this issue as a "security
vulnerability", then the Kamailio team should just take it for granted. All
IMHO of course.

Adding score is fine, but that's a bit post-factum. IMHO you need a score
when you have too many vulnerabilities to report. Kamailio as we already
established is not in this category yet.

-Max

On Wed, Sep 2, 2020 at 12:25 PM Henning Westerholt <hw at 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 <sobomax at sippysoft.com>
> *Sent:* Wednesday, September 2, 2020 9:15 PM
> *To:* Henning Westerholt <hw at skalatan.de>
> *Cc:* Daniel-Constantin Mierla <miconda at gmail.com>; yufei.tao at gmail.com;
> Olle E. Johansson <oej at edvina.net>; Gerry | Rigatta <gjacobsen at rigatta.com>;
> Kamailio (SER) - Users Mailing List <sr-users at lists.kamailio.org>;
> jbrower at 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 <hw at 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
>


-- 
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
Tel (Canada): +1-778-783-0474
Tel (Toll-Free): +1-855-747-7779
Fax: +1-866-857-6942
Web: http://www.sippysoft.com
MSN: sales at sippysoft.com
Skype: SippySoft
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200902/c61bf0ef/attachment.htm>