* You are viewing Posts Tagged ‘Driver’

Skinny Channel Driver Remote Crash Vulnerability

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.

Remote Crash Vulnerability in SIP Channel Driver

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, 10.3.1
Asterisk Business Edition C.3.7.4

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

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

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.

Heap Buffer Overflow in Skinny Channel Driver

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,, 10.3.1

Driver for TOR3E ( Govarion ).

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

Problem H323 asterisk

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?


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@,40″) in new stack
> — Requested transfer capability: 0x00 – SPEECH
> — Making call to 1083@ without gatekeeper.
> Using for outbound call
> == New H.323 Connection created.
> — root is calling host 1083@
> — Call token is ip$localhost/19287
> — Call reference is 19287
> — DTMF Payload is 0x4235b48
> — Called 1083@
> Setting capabilities to 0xc (ulaw|alaw)
> Capabilities in preference order is (ulaw|alaw)
> DTMF mode is 8
> Allowed Codecs for ip$localhost/19287 (ip$
> 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
> 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

Asterisk unixODBC configuration files for MySQL and MariaDB

1.0 Asterisk + unixODBC

Having almost all of our Asterisk configuration based on our preferred Database Management System is one of the greatest advantages that we have at the moment to deploy a VoIP solution. Now, having the possibility of building and integrated and unified communication solution in a non-intrusive way for client’s company, while at the same time assuring scalability and flexibility, that’s a mayor thing. That’s precisely what we have at the moment of using Asterisk+unixODBC.

unixODBC “allows the user or the system administrator to easily configure an application to use any ODBC compliant data source. This is perhaps the single biggest advantage of coding an application to the ODBC API and to purchase these applications. Dyamic binding allows the end-user to pick a data source, ie an SQL Server, and use it for all data applications without having to worry about recompiling the application.”

“The unixODBC Project goals are to develop and promote unixODBC to be the definitive standard for ODBC on non MS Windows platforms. This is to include GUI support for both KDE and GNOME.

ODBC is an open specification for providing application developers with a predictable API with which to access Data Sources. Data Sources include SQL Servers and any Data Source with an ODBC Driver.” (unixODBC website)

In this article I’m making the following assumptions:

  • You are using CentOS
  • You are using MariaDB or MySQL (All MySQL connectors -PHP, Perl, Python, Java, MyODBC, Ruby, MySQL C connector etc- work unchanged with MariaDB)


2.0 Asterisk ODBC Installation

Follow this document in order to install Asterisk.

You’ll also need to install the Asterisk ODBC package and (optionally) the Asterisk Voicemail ODBC package (if you plan to store your voicemail using ODBC):

$ yum install asterisk16-odbc asterisk16-voicemail-odbcstorage


3.0 Install the MySQL-connector

$ yum install mysql-connector-odbc


4.0 Configuring the System File for unixODBC: odbcinst.ini

The system file odbcinst.ini contains information about ODBC drivers available to all users. You could have multiple drivers configured, so if you want to use MariaDB, PostgreSQL and ORACLE at the same time, here is where you would be configuring the drivers.

Create the following /etc/odbcinst.ini file

Description=MySQL ODBC 5.1 Driver

In the previous example, the ‘[MySQL]‘ part, is an identifier for this driver (you could call it whatever you want, just remember the name later). The ‘driver‘ setting indicates where is located the MySQL Connector driver file. If you are using CentOS 64bit (or other distro), this might have a different location, you might want to try finding it using:

$ locate libmyodbc

… or you can use whatever method you feel comfortable with (e.g. find command)

The ‘setup‘ and ‘usercount‘ parts can be ignored, as they are used when you create the file using a GUI (which is not our case right now).

  • For extensive documentation about how to correctly configure unixODBC drivers file and Data Source Name file, visit the exceptional documentation provided by Nick Gorham at unixODBC website.
  • Information about configuring MySQL ODBC Connector and underlying details can be found on MySQL ODBC Connector documentation’s page.


5.0 Configuring the DSN (Data Source Name) File for unixODBC: odbc.ini

The DSN file contains information about DSN’s available to all users. These “System DSN’s” are useful for application such as web servers that may not be running as a real user and so will not have a home directory to contain a .odbc.ini file.

Create the following /etc/odbc.ini file:

Description=Asterisk Data Source Name
; SOCKET=/var/lib/mysql/mysql.sock

In this example ‘[asterisk-dsn]‘ is the DSN identifier, the ‘Driver‘ part indicates what driver to use from your odbcinst.ini file (section 4.0 of this guide). ‘Server‘ indicates where to connect using the driver belonging to this section (in this example, ‘localhost’). ‘UID‘ and ‘PWD‘ are the username and password of a user that has proper privileges on the database defined by ‘DATABASE‘. You might want to indicate a ‘SOCKET’, instead of a ‘PORT’ (only for local connections: localhost). This is the socket where MariaDB/MySQL listen to, in my system:

[root@asteriskfaqs etc]# netstat -n -l | grep -i mysql
unix  2      [ ACC ]     STREAM     LISTENING     14847  /var/lib/mysql/mysql.sock


6.0 Testing your unixODBC configuration

If everything went OK, then this command should help you test your configuration:

[root@asteriskfaqs etc]# echo ‘select now()’ | isql asterisk-dsn
| Connected!                            |
|                                       |
| sql-statement                         |
| help [tablename]                      |
| quit                                  |
|                                       |
SQL> +——————–+
| now()              |
| 2011-06-30 17:57:01|
SQLRowCount returns 1
1 rows fetched


7.0 Avoiding deadly pitfalls

  • Get sure that the database configured in the DSN file exists! (you could get weird errors if it doesn’t, but none of the meaningful)
  • Get user that the username in the DSN file is valid (it exists) and has privileges over the indicated database
  • Get sure to provide the correct file name in the odbcinst.ini file, when configuring the driver


I hope this post has been useful to you. I’ll try to keep it updated and keeping improving it over the time. If there’s something you don’t understand, just drop me a line.