[reSIProcate] memory leak bug in TransactionState
Byron Campen
bcampen at estacado.net
Thu Aug 24 15:36:03 CDT 2006
Ok, here is bug #3 (this is a corollary of bug #2). If an attacker
sends us an INVITE with CANCEL in the CSeq, the TU's response hits
this code:
*snip*
else if (isResponse(msg, 100, 699) && isFromTU(msg))
{
SipMessage* sip = dynamic_cast<SipMessage*>(msg);
int code = sip->header(h_StatusLine).responseCode();
switch (sip->header(h_CSeq).method())
{
//...
case CANCEL:
assert(0);
break;
*snip*
It seems to me that the stack is being liberal for stuff coming off
the wire, and strict for stuff coming from the TU. This becomes
problematic because we are expecting the TU to fix garbage that the
stack hands it. We should not be expecting the TU to do protocol-
repair on stuff that we, the stack, will need to use.
I propose that we ensure that CSeq is well-formed, and matches the
RequestLine (if any), for every message that comes off the wire. If
the stack is going to be making use of it, it is the stack's
responsibility to ensure that it is usable.
Best regards,
Byron Campen
> Alright, suppose something sends us an INVITE with a non-matching,
> unknown method in CSeq. This will parse successfully, since it is
> well-formed. This INVITE will be sent up to the TU, which will
> reply (hopefully). Unfortunately, TransactionState ingores the
> response...
>
> *snip*
> else if (isResponse(msg, 100, 699) && isFromTU(msg))
> {
> SipMessage* sip = dynamic_cast<SipMessage*>(msg);
> int code = sip->header(h_StatusLine).responseCode();
> switch (sip->header(h_CSeq).method())
> {
> //...
>
>
> default:
> //StackLog (<< "Received response to non invite or
> cancel. Ignoring");
> delete msg;
> break;
>
> *snip*
>
>
> So, should the stack be verifying that the method in CSeq matches
> the request-line when a request comes in? This is the second bug I
> have found in the last hour or so that could be solved by adding
> this check.
>
> Best regards,
> Byron Campen
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.sipfoundry.org
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20060824/220bceac/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2369 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20060824/220bceac/attachment.bin>
More information about the resiprocate-devel
mailing list