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

[Fred Posner]

As I was drafting my response, Alex articulated a response better than
I could dream.

I agree with the project response, Daniel's response, and also would
like to add that remove_hf_re has been here since 1.5 and is not
vulnerable to the scenario described.

Internally, the headers would need to be known and if internal there's
more security concern other than this of course.

Externally (or from un-trusted sources), you're hopefully stripping
all X-, or other type headers that you would be using internally. In
this case, the re method would still not need updating.

This scenario is not obtaining private information, memory leaks,
system crash. It is a valid concern when using an exact replace on an
arbitrary header should that arbitrary header be used for some
security method.

This said, if your security can be evaded with a plain text header,
you may wish to consider adding an additional measure such as source,
auth, etc.

As time progresses, attack metrics change. If a criteria meets a major
announcement, the project has shown and demonstrated that information
will be released in a security announcement, for example:


https://www.kamailio.org/w/2018/07/kamailio-security-announcement-for-kamailio-core/

--fred

On Wed, 2020-09-02 at 13:56 -0400, Alex Balashov wrote:
> 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 at 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 at sippysoft.com 
> > <mailto:sobomax at sippysoft.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 at lists.kamailio.org
> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> > 
> 
>