[OpenSIPS-Users] Register Module GRUU Length Calculation Errors

Tolga Tarhan tolga at netbrains.com
Mon Apr 29 01:34:37 CEST 2013


All,

I've discovered another bug in the register module's GRUU handling. This
time, the issue is that an incorrect length is calculated for a temp GRUU
before it is base64 encoded. This causes the GRUU to not match when it's
decoded (since two extra characters of garbage get encoded on accident).

In the 1.9.0 source, the problem is in modules/registrar/reply.c on line
191. The temp GRUU is calculated as time_len + aor->len + instance->len +
callid->len + 3, however, when instance is actually appended to the memory
buffer, two characters (the leading and trailing angle brackets) are
removed. This results in the reported length being two characters too long
and two extra characters of garbage being included in the base64 encoded
string.

I've created and verified a patch for this problem. It can be found here:
http://netbrains-misc.s3.amazonaws.com/opensips/opensips-register-make-gruu-wrong-length.patch

Additionally, there appears to be a possibly related bug in
modules/registrar/common.c on line 141 where the call id length after
base64 decoding is inexplicably reduced by one. This may have been a
previous attempt by someone to partially workaround the encoding bug above,
but it isn't correct, as the last character of the GRUU call id is lost.

I've created and verified a patch for this as well. It can be found here:
http://netbrains-misc.s3.amazonaws.com/opensips/opensips-lookup-gruu-wrong-length.patch

For what it it's worth, the assumption that sip.instance contains
angle-brackets may be wrong. I believe that it's always supposed to, but
assuming that it does is probably problematic and could be a source of even
bigger problems if the instance is less than two characters long (where the
memcpy would just grab random memory, I think). My patch doesn't address
this aspect, however.

Please let me know if there's something else I need to do to get these
patches accepted upstream.

Thanks,
Tolga Tarhan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20130428/e6ac311b/attachment.htm>


More information about the Users mailing list