<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<tt>Hello Tolga,<br>
<br>
Once again, thank you for the report and patch - Vlad, the
maintainer of the GRUU code will take a look on this asap and make
the fix.<br>
<br>
Thanks and regards,<br>
</tt>
<pre class="moz-signature" cols="72">Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a class="moz-txt-link-freetext" href="http://www.opensips-solutions.com">http://www.opensips-solutions.com</a></pre>
<br>
On 04/29/2013 02:34 AM, Tolga Tarhan wrote:
<blockquote
cite="mid:CAM3QAwQ99BdujFViuOwW1oMD08wa5qPurGuMn6704-QR3J7m8w@mail.gmail.com"
type="cite">
<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 moz-do-not-send="true"
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 moz-do-not-send="true"
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>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a>
</pre>
</blockquote>
</body>
</html>