<div dir="ltr">All,<div><br></div><div style>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). </div>
<div style><br></div><div style><div>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.</div>
<div><br></div><div>I've created and verified a patch for this problem. It can be found here: <a href="http://netbrains-misc.s3.amazonaws.com/opensips/opensips-register-make-gruu-wrong-length.patch">http://netbrains-misc.s3.amazonaws.com/opensips/opensips-register-make-gruu-wrong-length.patch</a></div>
<div><br></div><div style>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.</div>
<div><br></div><div>I've created and verified a patch for this as well. It can be found here: <a href="http://netbrains-misc.s3.amazonaws.com/opensips/opensips-lookup-gruu-wrong-length.patch">http://netbrains-misc.s3.amazonaws.com/opensips/opensips-lookup-gruu-wrong-length.patch</a></div>
<div><br></div><div style>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.</div>
<div><br></div><div>Please let me know if there's something else I need to do to get these patches accepted upstream.</div><div><br></div><div>Thanks,</div><div>Tolga Tarhan</div></div></div>