[OpenSIPS-Users] About the "Resource List Server" of Presence and OpenXCAP
Hi Sir/Madam,
I'm trying to set up Presence service.
Seems the manual https://www.opensips.org/Documentation/Tutorials-RLS and
http://openxcap.org/presence-tutorial/ are out of date.
In the manual, modparam("rls", "server_address", "RLS_SERVER_ADDRESS"), but the
"server_address" parameter is NOT in the new version
https://opensips.org/docs/modules/3.3.x/rls.html
Is there any updated manual, useing external OpenXCAP fine?
And about the client Blink could test Presence service or NOT?
Thanks!
BR,
Sparkle Zou___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Best practices regarding exec module command injection
Thanks Bogdan. I realized the escape approach will not work, since you
cannot escape single quotes (') within a single quoted string in bash.
So that rules out escaping, regardless of whether "s.escape.common" or
"re.subst" is used (unless we surround our variables with double
quotes, but that would mean escaping a whole bunch of different
characters with large room for error).
The "exec" module documentation has an example where "re.subst" is
instead used for removing single quotes altogether:
exec("update-stats.sh '$(ct{re.subst,/'//g})'");
However, that could change the content of the variable which might not
be desirable.
Perhaps the best option is to use the "envavp" parameter when calling
"exec", to pass the user-defined variables as ENV variables instead.
That would completely avoid the injection issue.
So another question regarding that, if that's ok:
exec has this form:
exec(command, [stdin], [stdout], [stderr], [envavp])
Since "[envavp]" is last in the parameter list: how would you pass in
the "envavp" parameter to "exec" without also using the "stdin",
"stdout" and "stderr" parameters? The exec call will block if "stdout"
is provided.
Reference: https://opensips.org/html/docs/modules/3.1.x/exec.html#func_exec
Regards,
Erik
Den fre 9 sep. 2022 kl 14:24 skrev Bogdan-Andrei Iancu :
>
> TO be honest I don;t know for sure what chars/sequences has to be
> escaped being shell safe. The s.escape.common may not be enough, but you
> can use the re.subst [1] to manually escape more stuff
>
> [1] https://www.opensips.org/Documentation/Script-Tran-3-2#re.subst
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>https://www.opensips-solutions.com
> OpenSIPS Summit 27-30 Sept 2022, Athens
>https://www.opensips.org/events/Summit-2022Athens/
>
> On 9/9/22 11:57 AM, Erik H wrote:
> > Hi Bogdan,
> >
> > Thanks for the reply! What about the general case, where it's not
> > necessarily $tu that is being used but any user-supplied variable?
> > Would s.escape.common suffice to avoid command injection?
> >
> > Regards,
> > Erik
> >
> > Den tors 8 sep. 2022 kl 11:07 skrev Bogdan-Andrei Iancu
> > :
> >> Hi Erik,
> >>
> >> The $tu is the TO URI, so it should follow the URI syntax, which does
> >> not allow shell specific chars in it (like " ' | > aso). So it should
> >> be safe. Nevertheless, you should force a URI specific parsing using the
> >> {uri} transformation and try to separately push as params the username
> >> and domain - again, just to be safe.
> >>
> >> Regards,
> >>
> >> Bogdan-Andrei Iancu
> >>
> >> OpenSIPS Founder and Developer
> >> https://www.opensips-solutions.com
> >> OpenSIPS Summit 27-30 Sept 2022, Athens
> >> https://www.opensips.org/events/Summit-2022Athens/
> >>
> >> On 9/7/22 5:39 PM, Erik H wrote:
> >>> Hi!
> >>>
> >>> What are the recommended practices to avoid command injection when
> >>> using the exec module with user-defined variables as arguments?
> >>>
> >>> For example, say we have this code:
> >>>
> >>> exec("/home/.../myscript.sh '$tu'")
> >>>
> >>> (or with whatever user-defined value other than $tu we may want to use)
> >>>
> >>> Would this be vulnerable to command injection, or does OpenSIPS
> >>> recognize that the quoted "$tu" value should be escaped? If it is
> >>> vulnerable, how can we best avoid this? Does it suffice to use
> >>> s.escape.common on the value?
> >>>
> >>> Regards,
> >>> Erik
> >>>
> >>> ___
> >>> Users mailing list
> >>> Users@lists.opensips.org
> >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Best practices regarding exec module command injection
Hi again. Sorry, I should have read the documentation more carefully.
It has an example of such a scenario, with where stdin and envavp is
provided, and stdout and stderr are omitted:
exec("/home/../myscript.sh", "this is my $var(input) for exec\n", , ,
$avp(env));
Never mind then! Thanks for your help!
Regards,
Erirk
Den tors 22 sep. 2022 kl 16:34 skrev Erik H :
>
> Thanks Bogdan. I realized the escape approach will not work, since you
> cannot escape single quotes (') within a single quoted string in bash.
> So that rules out escaping, regardless of whether "s.escape.common" or
> "re.subst" is used (unless we surround our variables with double
> quotes, but that would mean escaping a whole bunch of different
> characters with large room for error).
>
> The "exec" module documentation has an example where "re.subst" is
> instead used for removing single quotes altogether:
>
> exec("update-stats.sh '$(ct{re.subst,/'//g})'");
>
> However, that could change the content of the variable which might not
> be desirable.
>
> Perhaps the best option is to use the "envavp" parameter when calling
> "exec", to pass the user-defined variables as ENV variables instead.
> That would completely avoid the injection issue.
>
> So another question regarding that, if that's ok:
>
> exec has this form:
>
> exec(command, [stdin], [stdout], [stderr], [envavp])
>
> Since "[envavp]" is last in the parameter list: how would you pass in
> the "envavp" parameter to "exec" without also using the "stdin",
> "stdout" and "stderr" parameters? The exec call will block if "stdout"
> is provided.
>
> Reference: https://opensips.org/html/docs/modules/3.1.x/exec.html#func_exec
>
> Regards,
> Erik
>
> Den fre 9 sep. 2022 kl 14:24 skrev Bogdan-Andrei Iancu :
> >
> > TO be honest I don;t know for sure what chars/sequences has to be
> > escaped being shell safe. The s.escape.common may not be enough, but you
> > can use the re.subst [1] to manually escape more stuff
> >
> > [1] https://www.opensips.org/Documentation/Script-Tran-3-2#re.subst
> >
> > Regards,
> >
> > Bogdan-Andrei Iancu
> >
> > OpenSIPS Founder and Developer
> >https://www.opensips-solutions.com
> > OpenSIPS Summit 27-30 Sept 2022, Athens
> >https://www.opensips.org/events/Summit-2022Athens/
> >
> > On 9/9/22 11:57 AM, Erik H wrote:
> > > Hi Bogdan,
> > >
> > > Thanks for the reply! What about the general case, where it's not
> > > necessarily $tu that is being used but any user-supplied variable?
> > > Would s.escape.common suffice to avoid command injection?
> > >
> > > Regards,
> > > Erik
> > >
> > > Den tors 8 sep. 2022 kl 11:07 skrev Bogdan-Andrei Iancu
> > > :
> > >> Hi Erik,
> > >>
> > >> The $tu is the TO URI, so it should follow the URI syntax, which does
> > >> not allow shell specific chars in it (like " ' | > aso). So it should
> > >> be safe. Nevertheless, you should force a URI specific parsing using the
> > >> {uri} transformation and try to separately push as params the username
> > >> and domain - again, just to be safe.
> > >>
> > >> Regards,
> > >>
> > >> Bogdan-Andrei Iancu
> > >>
> > >> OpenSIPS Founder and Developer
> > >> https://www.opensips-solutions.com
> > >> OpenSIPS Summit 27-30 Sept 2022, Athens
> > >> https://www.opensips.org/events/Summit-2022Athens/
> > >>
> > >> On 9/7/22 5:39 PM, Erik H wrote:
> > >>> Hi!
> > >>>
> > >>> What are the recommended practices to avoid command injection when
> > >>> using the exec module with user-defined variables as arguments?
> > >>>
> > >>> For example, say we have this code:
> > >>>
> > >>> exec("/home/.../myscript.sh '$tu'")
> > >>>
> > >>> (or with whatever user-defined value other than $tu we may want to use)
> > >>>
> > >>> Would this be vulnerable to command injection, or does OpenSIPS
> > >>> recognize that the quoted "$tu" value should be escaped? If it is
> > >>> vulnerable, how can we best avoid this? Does it suffice to use
> > >>> s.escape.common on the value?
> > >>>
> > >>> Regards,
> > >>> Erik
> > >>>
> > >>> ___
> > >>> Users mailing list
> > >>> Users@lists.opensips.org
> > >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Call extender technology failing to work
It worked fine, many thanks.
I am very grateful for this list.
On Thu, Sep 22, 2022 at 11:44 AM Jonathan Abrams wrote:
> Hi Michael,
>
> It looks like you may need to send an OK to the caller side before
> invoking the asynchronous sleep. Something like:
>
> sl_send_reply(200, "OK");
>
> - Jon Abrams
>
> On Thu, Sep 22, 2022 at 10:29 AM Saint Michael wrote:
>
>> Dear friends
>> I have a call extender technology that is very useful, but it has a
>> problem, and my support provider, who wrote it, is missing in action.
>>
>> This is the issue: the call extender technology does not confirm the BYE
>> to the caller
>> if ($avp(hold_seconds) > 0) {
>> $avp(total_duration) =
>> $DLG_lifetime + $avp(hold_seconds);
>>
>> cache_store("local","start_$ci","$dlg_val(start_time)",180);
>>
>> cache_store("local","duration_$ci","$avp(total_duration)",180);
>> async( sleep($avp(hold_seconds)),
>> bye_resume );
>> exit;
>> }
>> if that code executes, because hold_seconds > 0, then we don't confim the
>> BYE and we keep
>> getting more BYEs.
>> The call extender technology should confirm the BYE to the caller as
>> normally, and it does not. It should hold the call open towards the callee,
>> not the caller. Can you suggest a change in the code?
>> I guess the new line if code should be called before
>> $avp(total_duration) = $DLG_lifetime + $avp(hold_seconds);
>>
>> Many thanks for your help
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Call extender technology failing to work
Hi Michael,
It looks like you may need to send an OK to the caller side before invoking
the asynchronous sleep. Something like:
sl_send_reply(200, "OK");
- Jon Abrams
On Thu, Sep 22, 2022 at 10:29 AM Saint Michael wrote:
> Dear friends
> I have a call extender technology that is very useful, but it has a
> problem, and my support provider, who wrote it, is missing in action.
>
> This is the issue: the call extender technology does not confirm the BYE
> to the caller
> if ($avp(hold_seconds) > 0) {
> $avp(total_duration) =
> $DLG_lifetime + $avp(hold_seconds);
>
> cache_store("local","start_$ci","$dlg_val(start_time)",180);
>
> cache_store("local","duration_$ci","$avp(total_duration)",180);
> async( sleep($avp(hold_seconds)),
> bye_resume );
> exit;
> }
> if that code executes, because hold_seconds > 0, then we don't confim the
> BYE and we keep
> getting more BYEs.
> The call extender technology should confirm the BYE to the caller as
> normally, and it does not. It should hold the call open towards the callee,
> not the caller. Can you suggest a change in the code?
> I guess the new line if code should be called before
> $avp(total_duration) = $DLG_lifetime + $avp(hold_seconds);
>
> Many thanks for your help
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Call extender technology failing to work
Dear friends
I have a call extender technology that is very useful, but it has a
problem, and my support provider, who wrote it, is missing in action.
This is the issue: the call extender technology does not confirm the BYE to
the caller
if ($avp(hold_seconds) > 0) {
$avp(total_duration) =
$DLG_lifetime + $avp(hold_seconds);
cache_store("local","start_$ci","$dlg_val(start_time)",180);
cache_store("local","duration_$ci","$avp(total_duration)",180);
async( sleep($avp(hold_seconds)),
bye_resume );
exit;
}
if that code executes, because hold_seconds > 0, then we don't confim the
BYE and we keep
getting more BYEs.
The call extender technology should confirm the BYE to the caller as
normally, and it does not. It should hold the call open towards the callee,
not the caller. Can you suggest a change in the code?
I guess the new line if code should be called before
$avp(total_duration) = $DLG_lifetime + $avp(hold_seconds);
Many thanks for your help
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Failed to trigger pkg stats in logs
Hi Bogdan,
Sorry, I just realized that I haven't turned off the auto-scaler for UDP
processes so you're right - that error is for them. I've switched TCP
auto-scaling off due to all my previous issues that I wasn't able to
overcome.
auto_scaling_profile = PROFILE_UDP
scale up to 32 on 80% for 4 cycles within 5
scale down to 2 on 10% for 5 cycles
udp_workers=1 use_auto_scaling_profile PROFILE_UDP
socket=udp:10.x.x.x:5060
socket=udp:103.x.x.x:7060
In regards to pkg memory - I only have 32MB as -M parameter, maybe that's
not enough? I'm not sure how to do 'pkg dump' - never tried to do that
before, is this what you're asking about?
Sep 21 18:52:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats
for process 45
opensips-cli -x mi ps
{
"Processes": [
...
{
"ID": 45,
"PID": 310115,
"Type": "SIP receiver udp:103.x.x.x:7060"
}
]
}
root@osgw1:~# opensips-cli -x mi mem_pkg_dump 310115
ERROR: command 'mem_pkg_dump' returned: 500: Internal error
Best regards,
Yury.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
