[OpenSIPS-Users] s.escape.param transformation

[Ben Newlin]

Bogdan,

Yes, I tried it with both single and double quotes and still received the error. I think it is clear from the error that printf is being used by opensipsctl, and the ‘%’ character is used by printf for formatting.

Thanks,
Ben


From: Bogdan-Andrei Iancu <bogdan at opensips.org>
Date: Wednesday, October 18, 2017 at 3:17 AM
To: Ben Newlin <Ben.Newlin at genesys.com>, OpenSIPS users mailling list <users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] s.escape.param transformation

Hi Ben,

It may be related to how the shell is doing it's own escaping. have you tried

$ opensipsctl fifo cache_store local IMC '713%20MYH'

?

Regards,


Bogdan-Andrei Iancu

  OpenSIPS Founder and Developer

  http://www.opensips-solutions.com<http://www.opensips-solutions.com>
On 10/17/2017 05:24 PM, Ben Newlin wrote:
Thanks very much, Bogdan.

While testing this, I also found something else which may or may not still be an issue (I’m still using 1.11.11).

I am using the parameter escape functionality on data that is being inserted into a local cache using cachedb_local module. In writing some tests for this functionality, I was attempting to use the MI interface to insert an escaped value into the cache and received errors.

$ opensipsctl fifo cache_store local IMC "713%20MYH"
/usr/local/lib64/opensips/opensipsctl/opensipsctl.unixsock: line 67: printf: `M': invalid format character

It seems that the printf function is being used somehow to insert the value into the cache and it is interpreting the % as a format placeholder.

Using printf escaping on the string makes it work:

$ opensipsctl fifo cache_store local IMC "713%%20MYH"

Not sure if this is a bug or if it should be documented or anything. Just thought I would mention it.

Thanks,
Ben Newlin


From: Bogdan-Andrei Iancu <bogdan at opensips.org><mailto:bogdan at opensips.org>
Date: Tuesday, October 17, 2017 at 4:52 AM
To: OpenSIPS users mailling list <users at lists.opensips.org><mailto:users at lists.opensips.org>, Ben Newlin <Ben.Newlin at genesys.com><mailto:Ben.Newlin at genesys.com>
Subject: Re: [OpenSIPS-Users] s.escape.param transformation

Hi Ben,

Thank you for the report. I double checked with the RFC3261 and you are right.

I made the fix on head, 2.3 and 2.2 versions, see:
    https://github.com/OpenSIPS/opensips/commit/b5094f0dc6a4f52555f9cca1ea9df7c846749482<https://github.com/OpenSIPS/opensips/commit/b5094f0dc6a4f52555f9cca1ea9df7c846749482>

Best regards,



Bogdan-Andrei Iancu

  OpenSIPS Founder and Developer

  http://www.opensips-solutions.com<http://www.opensips-solutions.com>
On 10/16/2017 09:12 PM, Ben Newlin wrote:
Hi,

I think I’ve found an error in the escape transformations for parameters. The {s.escape.param} transformation is escaping many characters it shouldn’t.

For example, the following code:

$var(test) = "MYH 713";
xlog("L_ALERT", "test: $(var(test){s.escape.param})\n");

produces this output:

test: %4d%59%48%20%37%31%33

Only the space character should have been converted, not all characters.

In looking through the source code, I think the problem is that the alphanum group of allowed characters is completely missed during the transformation in the escape_param function in strcommon.c. For comparison, the escape_user function has the following code allowing alphanum characters to copied without conversion:

if (isdigit((int)*p) || ((*p >= 'A') && (*p <= 'Z')) || ((*p >= 'a') && (*p <= 'z')))
{
        *at = *p;
} else {
        switch(*p) {
…
I think similar logic is supposed to be in escape_param but is absent, resulting in all alphanum characters being converted to hex.

Thanks,

Ben Newlin






_______________________________________________

Users mailing list

Users at lists.opensips.org<mailto:Users at lists.opensips.org>

http://lists.opensips.org/cgi-bin/mailman/listinfo/users<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20171018/e35ef700/attachment-0001.html>