Hello list,
Hope you are all well.
Under some load test simulations I've been facing cases where the command
Kamailio sends to RTPEngine times out with such message:
send_rtpp_command(): timeout waiting reply for command "" from RTP proxy
After checking RTPEngine logs, I can see the command was
Hello Maxim,
I think it would be a good idea to start a new thread to discuss process
improvements, so only a few comments.
As mentioned from Alex already, this is an open source project and not a
company where the CISO will check that all documented policies are done and
checked to not lose
Henning, well, sorry I respectfully disagree. The "for example" clause
clearly defines the following list as non-exclusive. What about let's say
SQL injection attacks? Are those "serious" enough? Or someone being able to
bypass authentication mechanisms? Any other 100500 potential ways to
exploit
Hello Maxim,
have a look to the first sentence:
“A security vulnerability is (for example) when a user of Kamailio can cause
Kamailio to crash or lock up by sending messages to the server process.”
So there is some limitation regarding vulnerability criticality defined in
there. But of course
On Wed, Sep 2, 2020 at 11:30 AM Henning Westerholt wrote:
> Hello Maxim,
>
>
>
> thank you for the clarification, appreciated.
>
No worries, hope to have a civilized discussion.
> Just one clarification, my comment regarding the advisory from 2018 was
> not meant as advertisement etc..
>
Hello Maxim,
thank you for the clarification, appreciated.
Just one clarification, my comment regarding the advisory from 2018 was not
meant as advertisement etc..
One suggestion to objectify the whole discussion, there exists a well-known and
accepted metric for vulnerabilities: CVSS [1]
If
On 2020-09-02 14:21, Fred Posner wrote:
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:
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
In the eyes of people who are not doing the work themselves, everything
always warrants something.
The reality of open-source is it cannot be all things to all people. If
you want to be a security-conscious user of Kamailio, you need to
monitor the mailing lists.
Doubtless, very, very
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
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
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
Hi,
Thanks @Abdirahman A. Osman
I have tried having custom dns server by changing the core-dns config file.
sip.example.com:53 {
errors
cache 30
forward . 10.152.183.91
}
I could able to resolve the domain names properly. But now the issue is
Dear Team,
I am unable to play media file on caller/callee. I am using
rtpproxy_stream2uas/rtproxy_stream2uac to play media file.
RTPProxy put on remote machine. Kamailio server are on another machine. When
do call media relay by rtpproxy well. Now it is fine.
But issue when hold the
Hi,
The security tests were done to find theoretically possible flaws and help
make Kamailio "bullet proof". Well it's already a lot more robust than most
others. I think Daniel and Henning have made it very clear about the scope
of the bug.
For me if it is something that's been there for so
Hi Daniel,
the word “only” makes it sound like a small issue, at least in my ears.
Best
Gerry
> On 2 Sep 2020, at 13:33, Daniel-Constantin Mierla wrote:
>
> Hello,
>
> On 02.09.20 12:53, Gerry | Rigatta wrote:
>> [...]
>>
>> I can only guess that Maxim took offence with your wording
Hello,
On 02.09.20 12:53, Gerry | Rigatta wrote:
> [...]
>
> 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
>>>
please provide further details why is downplaying. Have you
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 -
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
Hello,
you also have to be careful not to have such lines in comments or in the
wrong order. Maybe just grep the lines starting with #! and be sure you
have proper nesting of if[n]def and endif.
Another thing to check is if you have include/import files and if yes,
that their content is correct.
The feature request is for SIP listen sockets, the evapi use different
ones. But indeed, that can be an approach.
In other words, at this moment is not supported. However, be aware that
tcp/tls connections can by cut by routers/firewalls in the middle,
therefore the client app has to support
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
Hello Maxim,
we did the more extensive process in the past with issues that could lead to a
crash. You find the announcements in the archives and on the webpage in 2018,
let me know if you like a pointer to that. I don’t want to downplay it, but
this particular bug is in my opinion less
23 matches
Mail list logo
