2 Sep
2020
2 Sep
'20
8:56 p.m.
For whatever it's worth: IHO, the official project response to this
issue, and Daniel's in particular, was reasonable and proportional to
the severity of the problem.
As Daniel pointed out in his response:
1. "Of course, security is affected only if you pass security sensitive
data in such custom headers"
2. "The default kamailio.cfg is not using any custom headers, thus
no impact on it."
Or in other words: This is not a ubiquitous problem affecting a large
proportion of the installed base. Custom headers present a security risk
_ipso facto_. It is up to the implementor to make a reasonable and
informed risk assessment about using them.
It is true that #2 is less of a mitigating factor than #1; as someone
pointed out, the value of Kamailio is tied up in the core APIs it
provides as a "toolkit", rather than packaged configurations, as most
substantial implementations of Kamailio involve advanced use-cases and
extensive custom config-writing.
Nevertheless, some subsequent responses in this thread seem like
needless hyperventilation to stimulate "political energy" or energise
some kind of online outrage machine. This betrays a failure to see
forest for trees and a lack of adequate perspective on the objective
impact of this issue (medium), or a penchant for hysteria.
-- Alex
On 2020-09-02 13:48, jbrower(a)signalogic.com wrote:
Maxim is correct. *Anything* even remotely exploitable
must be
documented, fixed, and reported. Credibility with company security
officers, CFOs -- even with the press if something bad should ever
happen -- is crucial.
Whether there is an impacted standard is irrelevant. What standard ever
covered RowHammer, Spectre, etc ? If the exploit doesn't make sense
because "they would have access to other private data anyway" is an
assumption and therefore also irrelevant. Sophisticated hackers are
great programmers (as are Kamailio programmers), they work 24/7 (as we
do) -- who's to say how they might combine exploits in some way we
cannot yet imagine.
-Jeff
Quoting Maxim Sobolev <sobomax(a)sippysoft.com
<mailto:sobomax@sippysoft.com>>:
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Hey Daniel, Henning, Tao,
Thanks for commenting out. There are a lot of opinions for me to
address individually, so I will just clarify my opinion. The only
substantial difference I think is whether the issue at hand warrants a
security advisory to be issued by the Kamailio project or not. I
totally think that it does, but it looks like I am in the minority here.
Why do I think this way? Well, the first argument is a bit empirical.
It is hard to generalize out of sample size 1, but in like 90%
engagements where I had to use SIP Proxy element and integrate it with
different SIP elements I ended up using "private headers" for passing
information between elements within that setup. So the task of
cleaning up those headers at the edge of the network is very relevant
at least to some users. It also matches Sandro's assessment, which
gives it at least some credibility.
Second, a more general one. Not only I have some experience in
software development field, but also I got a chance to participate in
much bigger and older open source projects (i.e. FreeBSD Project, 400+
active developers, 1,000+ contributors) so I have seen how security is
dealt with properly in a mature open source project. You guys might
fancy the fact that Kamailio issued the last security advisory in 2018
as a "code quality" indicator, but to me that shows a total lack of
proper security process. With the code base of its size, I'd expect
at least several security issues of various criticality being found
per year. I frankly don't understand the pushback I am getting. It
almost looks like issuing such advisory is viewed as harmful and
damaging on project "spotless" reputation or something. However in my
view it would show respect to users and understanding that many of
those users might be using it in a way that differs from its creators.
It might come as a surprise to some of you, but 95% of Kamailio users
are not reading this and those lists or following Sandro's work in
general. However, if there were a section "Security Advisories" on
kamailio.org <http://kamailio.org> that would be the place to go. And
those users are often not individuals, but companies building their
products and solutions atop of Kamailio.
Also properly issued security advisory helps package maintainers, any
linux distro of decent size has its own process to handle and
disseminate those among their own users to update package ASAP. But if
Kamailio chooses to not issue any it basically cuts itself out of that
process.
And last but not least, to the remark that I need to step in and fix
things, well I am hardly a person to do that. Too many projects and
too little time, however I also don't think I cannot voice my opinion,
or can I? By the way I know at least one person in the Kamailio
community that might be more fit as a "Kamailio Security
Officer": Olle E. Johansson. Olle, what's your take on this? Does
this problem warrants security advisory?
-Max
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users