The Bug That Wouldn't Die

[wardmundy]

For those of you that have been following the SIP CallerID Stack Overflow Vulnerability story, suffice it to say we thought we had this one put to bed.

Well, not so fast, says our fearless whiz kid, Tom King. In putting the finishing touches on the new update-programs and update-fixes (which you really need to run!), Tom happened to notice that the new SIP patch was being executed with the latest and greatest PIAF-Purple. It includes Asterisk 1.8.2.1 which supposedly patched the SIP bug.

You can test whether your servers have the bug with the following command:

grep "(*ptr && out - outbuf < buflen - 1)" /usr/src/asterisk/main/*

If your system has the SIP bug, you'll get a null string. Otherwise, you'll see an entry from utils.c.

And, guess what, Asterisk 1.8.2.1 still has the bug. Stay tuned for Asterisk 1.8.2.2 coming to a server near you shortly.

 

[leifmadsen]

It was simply due to a failed merge. It has been resolved now.

http://bit.ly/hsrITt

Leif.

 

[darmock]

A failed merge can be a big thing if the users think that the SIP patch was applied. Luckily you guys just released 1.8.2.2 which I just finished testing and verifying that the patch is indeed there. Now just uploading into PIAF space and hopefully we will release it to our users momentarily.

To All

I have also modified update-fixes to ensure this critical patch is in place in all colors of PIAF 1.7.5.5.x

update-fixes will now look at your existing install of Asterisk and ensure you are patched. If you have already patched it by hand then nothing will be touched. If not the patch will be applied and then verified that it all was incorporated into the correct file. If it fails you will be notified and the original file will be restored. This applies to all colors of PIAF 1.7.5.5 and above



Tom

 

[darmock]

Gee Leif

We let the head office of Digium know as soon as I found the bug. As I look at our email trail Digium had word within about 5 minutes of me finding this little problem.

We also put out the info to our user base so they knew there was a problem. We put out a patch to fix this issue as soon as we knew. I did not realize that keeping our users informed of developments was garnering hits.


Tom

 

[wardmundy]

New PIAF-Purple with Asterisk 1.8.2.2 is now the default Purple download. Thanks, Tom!

 

[leifmadsen]

Ya my face is red. I've had a bad day (which is not at all a valid excuse for going off) and no one told me it was you guys who reported the problem until it was too late.

The only thing I saw was from an internal developer, who I presumed was the one who noticed the missing merge (since he was the one who created the patch).

Apologies again for my inappropriate message. I've deleted it.

Leif.

 

[dad311]

I would assume its safe to say that if you dont use SIP then you dont need to be concerned about this bug?

 

[wardmundy]

So long as your SIP port isn't exposed to the Internet.

 

[mickecarlsson]

Or if you have upgraded your FreePBX.

The FreePBX team released the fix for FreePBX 2.5, 2.6, 2.7 2.8 and the upcoming 2.9.

For those sorry (censored) out there running trixbox, get hacked or switch to PiaF

 

[malcolmd]

Or if pedantic is set to no, which is the default for 1.4 and 1.6. For 1.8, the default is "yes." The default for pedantic was changed in 1.8 for interoperability purposes and because of improvements in the SIP stack.

 

[blanchae]

Pedantic - Enable slow, pedantic checking of Call-ID's, multiline SIP headers and URI-encoded headers. Asterisk doesn't necessarily parse nested & encoded chars in SIP invites out to the proper chars. Like Polycoms would encode the "3" in HEX, so in the actual dialplan, Asterisk got something like "%23". Setting "pedantic=yes" tells Asterisk to parse the invite strings, etc to come up with a full decode and not to do it the easy way. (I'm not that smart, had to look it up....)

Sounds like it could result in a performance hit?

 

[malcolmd]

Pedantic - Enable slow, pedantic checking of Call-ID's, multiline SIP headers and URI-encoded headers. Asterisk doesn't necessarily parse nested & encoded chars in SIP invites out to the proper chars. Like Polycoms would encode the "3" in HEX, so in the actual dialplan, Asterisk got something like "%23". Setting "pedantic=yes" tells Asterisk to parse the invite strings, etc to come up with a full decode and not to do it the easy way. (I'm not that smart, had to look it up....)

Sounds like it could result in a performance hit?

More work is always more difficult, but I don't think anyone's tried to measure it. The SIP channel driver in Asterisk 1.8 is more efficient for lots of other tasks, so it could be a wash.

 

[luckman212]

Is there a place within the FreePBX / PiaF gui to enable pedantic=yes ? Or do I just have to add it to /etc/asterisk/sip_custom.conf ?