[reSIProcate] SipFrag parsing leads to heap corruption

["Sasha Youkhananov" <y_Sasha@xxxxxxxxxx>]

Hello resiprocate developers.

 

I build a soft phone application under Windows XP using dum and reciprocate (resiprocate-0.9.0-5019.tar.gz).

As a part of that application I have to implement basic call transfer scenario.

In order to do it I prepared a prototype that consists of 2 parts: transferor and transferee.

At first, session between them is established and then the transferor sends REFER message to the transferee. Transferee then composes the proper INVITE and sends it to transfer target (3^rd application).

The problem comes when my transferor gets first NOTIFY with “sipfrag” message body. The program (I tell you about debug mode) fails with heap checking error.

I examined the situation several times and found that SipFrag::parse() call leads to memory corruption.

Here is the call stack:

resip::DialogUsageManager::process ()

resip::DialogUsageManager::internalProcess ()

resip::DialogUsageManager::processRequest ()

resip::DialogSet::dispatch ()

resip::Dialog::dispatch ()

resip::Dialog::makeClientSubscription ()

resip::ClientSubscription::ClientSubscription ()

resip::BaseSubscription::BaseSubscription ()

resip::SipMessage::releaseContents ()

resip::LazyParser::checkParsed ()

resip::SipFrag::parse ()

resip::MsgHeaderScanner::scanChunk ()

resip::processMsgHeaderStatusLine ()

resip::SipMessage::setStartLine

 

So, during construction of BaseSubscription the original request with sip-frag body is copied into mLastRequest member. When copy constructor of SipMessage works it copies mContentsHfv of original request to mContentsHfv of message that is being constructed. The copy constructor of HeaderFieldValue copies exactly mFieldLength bytes to constructed object.

When SipFrag parser starts its processing it writes 4 consecutive bytes (according to its algorithm) in area that is located at the address: buffer + size. That address is behind the allocated memory (was previously allocated in HeaderFieldValue copy constructor) and in debug mode is used to store the internal heap data (4 consecutive 0xFD). Thus, the next memory allocation request in SipMessage::setStartLine fails.

 

In order to repair this situation I changed copy constructor of HeaderFieldValue type to following:

 

HeaderFieldValue::HeaderFieldValue (const HeaderFieldValue& hfv)

   : mField(0),

     mFieldLength(hfv.mFieldLength),

     mMine(true)

{

   //InfoLog (<< "Making a copy of a HFV" << hex << this);

   mField = new char[mFieldLength + 5];

   memcpy(const_cast<char*>(mField), hfv.mField, mFieldLength + 5);

}

 

Of course, this change will affect other stack parts which use this type, but I haven’t found more appropriate place to my fix.

I’m sure you can suggest the better way to repair it.

Wait for any answer about this problem.

 

P.S. the log file is attached.

 

Best Regards,

Sasha

 

Attachment: resiprocate.log
Description: resiprocate.log