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

Hello Gerry, the bugfix is already in the stable branches 5.2 and 5.3 included, as I wrote before. I will be included (as all of the fixes we do) in these Debian and RPM packages as soon as the respective stable releases were done. Cheers, Henning -- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://gilawa.com<https://gilawa.com/> From: sr-users &lt;sr-users-bounces(a)lists.kamailio.org&gt; On Behalf Of Gerry | Rigatta Sent: Wednesday, September 2, 2020 12:53 PM To: miconda(a)gmail.com; Kamailio (SER) - Users Mailing List &lt;sr-users(a)lists.kamailio.org&gt; Subject: Re: [SR-Users] Kamailio vulnerable to header smuggling possible due to bypass of remove_hf Hello Daniel, thank you for highlighting this potentially very harmful bug and for suggesting a quick fix with remove_hf_re. I can only guess that Maxim took offence with your wording here, which can be understood as downplaying the risk The only security risk in my opinion This bug is indeed a huge security risk if someone relies only on custom headers to prevent bad actors. This bug shows once again that one cannot be too paranoid and must have second and third level security. If not such bug can easily sink some small and medium sized telcos. Will the patch will be backported to the stable rpm and debian Kamailio repos, Version 5.2 upwards, promoted here: https://www.kamailio.org/w/download/ Cheers Gerry On 2 Sep 2020, at 09:31, Daniel-Constantin Mierla <miconda@gmail.com<mailto:miconda@gmail.com>> wrote: Hello Maxim, can you explain why I am downplaying the severity by my remarks? I presented where the bug is impacting, because the initial announcement sent by Sandro in different channels (not here, but other security related mailing lists) contained inaccurate information, respectively an example with P-Asserted-Identity, which was actually not affected by the bug. So I wanted to be clear is it only about the common header names. Maybe you haven't understood the issue or what I said, that it may affect security of the platforms where custom header names are used to pass sensitive data between Kamailio and other SIP systems (but not Kamailio, since Kamailio-to-Kamailio will use same custom header name matching). None of my deployments were affected. The remark for default config file is that many deployments revolve around it and it does not use with custom header names, implying also it was not discovered by analyzing the public project, but configs specific to a private deployment. And no worries, the issue was public from the day one, by mid of July, being discussed on our community Matrix channel (public one) when Torrey reported it based on Sandro's work and it was fixed within minutes to all maintained branches. The group of most active developers was informed, none reacted as being anything highly critical. Many other bugs were fixed meanwhile, but no security researcher spent time on them to see if there is any risk exposed. During the past years the Kamailio ecosystem had extensive collaboration with Sandro/EnableSecurity and Henning/Gilawa for security assessments and fuzzing, several reports being out based on their work. I am somehow pretty sure no other VoIP project did same level of security research during the same time interval. Sending the announcement on this mailing list was also discussed yesterday on Matrix channel and I said that sr-users is the appropriate place to do it. Since Sandro (and his team) did the hard work on finding issues in Kamailio, was his privilege to send the announcement. As mentioned in the first paragraph, Sandro also notified on many security-related lists, but I was not asked to review the initial announcement sent to other lists, it was done without being notified. I've seen it first time on VoIPSec list, thus I discussed with Sandro about amending it to be make it clear the common headers are not affected. Now, if you are here because you use Kamailio and have good interest in this application, then you are also part of Kamailio project, it is a community working together for mutual benefits. In other words, Kamailio project is not going to do anything special for you, but you can step forward and propose what should be done and if found useful for the community, start doing it. If you are here just to demand others do work for you for free, then you are in the wrong place. Cheers, Daniel On 02.09.20 06:43, Maxim Sobolev wrote: Thanks Daniel for patching up the bug, however I think you are downplaying severity of the problem at hand. You see, from the point of view of outside world, kamailio is not just engine and default config. All APIs that are provided are also part of the product, especially those "core" ones. As such, security issue with any such API is affecting the whole product. People using Kamailio expect those APIs do what documentation says they do, no more no less! What you are saying is basically any Kamailio installation any version under the sun except maybe dozen using default config is affected and has to be updated. My question therefore is "what Kamailio is going to do about it"? At the very least I'd expect fix to be merged into all actively maintained branches and official security advisory issued and distributed to all possible channels listing revisions and recommending upgrading ASAP. -Max On Tue., Sep. 1, 2020, 8:46 a.m. Daniel-Constantin Mierla, <miconda@gmail.com<mailto:miconda@gmail.com>> wrote: Hello, thanks Sandro for directing a lot of time and effort for stress testing and fuzzing Kamailio, it really helps to increase the security and stability of the application. In a very short summary version, the issue was caused by a bug in extracting the name of non-common standard headers (like X-My-Hdr), not stripping the white spaces between the name and the following : (colon). The common standard headers (like From, To, Authorization, P-Asserted-Identity, ...) use a different header name parsing and there is no impact in them. The only security risk in my opinion is when some bad actor learns about the custom header names (and their body format/content) you use to pass data between Kamailio and other SIP systems in your core platform, then trying to preset such headers in the SIP traffic. Of course, security is affected only if you pass security sensitive data in such custom headers. The default kamailio.cfg is not using any custom headers, thus no impact on it. The config fix for it (without any code upgrade) is replacing: remove_hf("X-My-Hdr"); with: remove_hf_re("X-My-Hdr"); As a funny fact, I tracked the faulty code back to at least release SER v0.8.11, out 18 years ago, so it is a very long living bug. Cheers, Daniel On 01.09.20 14:44, Sandro Gauci wrote: -- 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 _______________________________________________ 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 -- 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 _______________________________________________ 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