2 Sep
2020
2 Sep
'20
7:48 p.m.
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>om>:
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[1] 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
Links:
------
[1] http://kamailio.org