A previously developed patch dealt with a denial of service attack exploitable in the Skinny channel driver that occurred when certain messages are sent after a previously registered station sends an Off Hook message. Unresolved in that patch is an issue in the Asterisk 10 releases, wherein, if a Station Key Pad Button Message is processed after an Off Hook message, the channel driver will inappropriately dereference a Null pointer.

Similar to the problem solved with the previous patch, a remote attacker with a valid SCCP ID can use this vulnerability by closing a connection to the Asterisk server when a station is in the ”Off Hook” call state and crash the server.

Now the presence of a device for a line is checked in the appropriate channel callbacks, preventing the crash.

you can download the latest Asterisk packages in the download section, as usual.

Stay tunned for more security updates.

Asterisk Project Security Advisory – AST-2012-006

Product Asterisk
Summary Remote Crash Vulnerability in SIP Channel Driver
Nature of Advisory Remote Crash
Susceptibility Remote Authenticated Sessions
Severity Moderate
Exploits Known No
Reported On April 16, 2012
Reported By Thomas Arimont
Posted On April 23, 2012
Last Updated On April 23, 2012
Advisory Contact Matt Jordan < mjordan AT digium DOT com >
CVE Name

Description A remotely exploitable crash vulnerability exists in the
SIP channel driver if a SIP UPDATE request is processed
within a particular window of time. For this to occur, the
following must take place:

1. The setting ‘trustrpid’ must be set to True

2. An UPDATE request must be received after a call has been
terminated and the associated channel object has been
destroyed, but before the SIP dialog associated with the
call has been destroyed. Receiving the UPDATE request
before the call is terminated or after the SIP dialog
associated with the call will not cause the crash
vulnerability described here.

3. The UPDATE request must be formatted with the
appropriate headers to reflect an Asterisk connected line
update. The information in the headers must reflect a
different Caller ID then what was previously associated
with the dialog.

When these conditions are true, Asterisk will attempt to
perform a connected line update with no associated channel,
and will crash.

Resolution Asterisk now ensures a channel exists before performing a
connected line update, when that connected line update is
initiated via a SIP UPDATE request.

In Asterisk versions not containing the fix for this issue,
setting the ‘trustrpid’ setting to False will prevent this
crash from occurring (default is False)

Affected Versions
Product Release Series
Asterisk Open Source 1.8.x All versions
Asterisk Open Source 10.x All versions
Asterisk Business Edition C.3.x All versions

Corrected In
Product Release
Asterisk Open Source 1.8.11.1, 10.3.1
Asterisk Business Edition C.3.7.4

Patches
SVN URL Revision
http://downloads.asterisk.org/pub/security/AST-2012-006-1.8.diff v1.8
http://downloads.asterisk.org/pub/security/AST-2012-006-10.diff v.10

Links https://issues.asterisk.org/jira/browse/ASTERISK-19770

Asterisk Project Security Advisories are posted at
http://www.asterisk.org/security

This document may be superseded by later versions; if so, the latest
version will be posted at
http://downloads.digium.com/pub/security/AST-2012-006.pdf and
http://downloads.digium.com/pub/security/AST-2012-006.html

Revision History
Date Editor Revisions Made
04/16/2012 Matt Jordan Initial release.

Asterisk Project Security Advisory – AST-2012-006
Copyright (c) 2012 Digium, Inc. All Rights Reserved.
Permission is hereby granted to distribute and publish this advisory in its
original, unaltered form.

In the Skinny channel driver, KEYPAD_BUTTON_MESSAGE events are queued for processing in a buffer allocated on the heap, where each DTMF value that is received is placed on the end of the buffer. Since the length of the buffer is never checked, an attacker could send sufficient KEYPAD_BUTTON_MESSAGE events such that the buffer is overrun.

Now, the length of the buffer is now checked before appending a value to the end of the buffer.

Affected Versions:

• Product Release Series
• Asterisk Open Source 1.6.2.x All Versions
• Asterisk Open Source 1.8.x All Versions
• Asterisk Open Source 10.x All Versions

Corrected In Product Release:

• Asterisk Open Source 1.6.2.24, 1.8.11.1, 10.3.1

Hello List,

I have one TOR3-E (E1 version) card from Govarion that i used some years
ago, but it seems company stopped work.
Since website is down.
Is there somebody with good heart that could help me to get a driver for an
x86 and x86_64 for
this card?

Thank you so much,

Richard Palmeron

Do you have any network devices or VPN tunnels in between the Asterisk
and Avaya?

The reason I am asking it looks like a potential networking issue.

Has this setup ever worked before?

-Vladimir

On 7/27/2011 1:32 PM, troxlinux wrote:
> Hi list , I am connecting one avaya with asterisk by h323 and when I
> call to avaya becomes disconnected, this is my debug
>
>
> ippbx*CLI> h323 set debug on
> H.323 Debugging Enabled
> == Using SIP RTP CoS mark 5
> == Using SIP VRTP CoS mark 6
> — Executing [1083@mific:1] Dial(“SIP/4097-00000002″,
> “H323/1083@172.16.8.5:1720,40″) in new stack
> — Requested transfer capability: 0×00 – SPEECH
> — Making call to 1083@172.16.8.5:1720 without gatekeeper.
> Using 172.16.8.56 for outbound call
> == New H.323 Connection created.
> — root is calling host 1083@172.16.8.5:1720
> — Call token is ip$localhost/19287
> — Call reference is 19287
> — DTMF Payload is 0x4235b48
> — Called 1083@172.16.8.5:1720
> Setting capabilities to 0xc (ulaw|alaw)
> Capabilities in preference order is (ulaw|alaw)
> DTMF mode is 8
> Allowed Codecs for ip$localhost/19287 (ip$172.16.8.56:39935):
> Table:
> G.711-uLaw-64k <1>
> G.711-ALaw-64k <2>
> UserInput/hookflash <3>
> UserInput/basicString <4>
> Set:
> 0:
> 0:
> G.711-uLaw-64k <1>
> G.711-ALaw-64k <2>
> 1:
> UserInput/hookflash <3>
> 2:
> UserInput/basicString <4>
>
> — Sending SETUP message
> — Received RELEASE COMPLETE message…
> — ClearCall: Request to clear call with token
> ip$localhost/19287, cause EndedByRemoteBusy
> — Sending RELEASE COMPLETE
> ExternalRTPChannel Destroyed
> ExternalRTPChannel Destroyed
> ExternalRTPChannel Destroyed
> ExternalRTPChannel Destroyed
> — ClearCall: Request to clear call with token
> ip$localhost/19287, cause EndedByTransportFail
> — 1083 was busy
> == H.323 Connection deleted.
> == Everyone is busy/congested at this time (1:1/0/0)
> — Executing [1083@mific:2] Hangup(“SIP/4097-00000002″, “”) in new stack
> == Spawn extension (mific, 1083, 2) exited non-zero on ‘SIP/4097-00000002′
>
>
> I have perfectly compiled h323 in asterisk
>
> core show channeltypes
> Type Description Devicestate
> Indications Transfer
> ———- ———– ———–
> ———– ——–
> Local Local Proxy Channel Driver yes yes
> no
> Bridge Bridge Interaction Channel no no
> no
> H323 The NuFone Network’s Open H.323 Channel no yes
> no
> Console OSS Console Channel Driver no yes
> no
> USTM UNISTIM Channel Driver no yes
> no
> Phone Standard Linux Telephony API Driver no yes
> no
>
>
> any idea?
>
> regardss
>
>
>
>