Hi, Stefan,

Thanks for your reply.
” SipRemoveHeader ” is a good application to remove the header added by
“SipAddHeader” application. If the header is included in the receiving message by Asterisk(not added by “SipAddHeader”), can it be removed?
From my testing it doesn’t work.

Ding Peng
——————————————————————–

Hello,

I need to develop an application that will query (mostly reading) an existing MySQL CDR database. This database (named Asteriskcdrdb) was created during Freepbx 2.10 install on my asterisk 1.8 setup. This database has a single CDR table which is filled by Asterisk.

The tools I’m planning to use require this table to include a Primary Key. Is it safe to Alter this table telling it to use UniqueID column as a Primary Key ?

(Sure, I’ll test this on a database copy but I’m not confident my tests will cover everything)

Regards

Hi

I have some problem with monitor application when call i transferred in attended mode and the transfer occurs before call is answered.

Here is how it looks:

A calls —-> B(let’s assume ${UNIQUEUEID}=1)

exten => _XXXX,1,NoOp seme => n,Set(MONITOR_FILENAME

Looking for ideas and comments on my strategy for getting a bit of custom data into the CDR. It seems to work OK, but I’m open to better and/or more robust ways to do it.

Problem: get the customerid of the caller from our application into the CDR

Approach:
Before the Queue() command, save the caller’s channel name in a varible
_MMCALLERCHANNEL

In the Queue() connect macro, send that channel name along with other info to the application

The application determines the customerid and uses AMI Setvar to set variable MMCUSTOMERID on the given channel with the customerid. (Can’t use AGI in-line because the customer will be determined by an actual human sitting at a terminal during the call and may take a while.)

In the hangup extension, set CDR(customerid) to value of MMCUSTOMERID

Here is the code that is working

[queues]
exten =>sales,1,Verbose(2,${CALLERID(all)} entering the sales queue)
same =>n,Set(_MMCALLERCHANNEL=${CHANNEL(name)})
same =>n,Queue(sales,t,,,,,QueueConnected)
same =>n,Hangup()
exten =>h,1,NoOp(When a sales queue call is hung up)
same =>n,Set(CDR(customerid)=${MMCUSTOMERID})

[macro-QueueConnected]
exten =>s,1,NoOp()
same =>n,Monitor(wav,,mb)
same
=>n,Set(OPERATORID=${ODBC_OPERATORID_FROM_ADDRESS(${MEMBERINTERFACE})})
; userfield is mapped to operatorid in cdr_adaptive_odbc because setting operatorid directly doesn’t work here
same =>n,Set(CDR(userfield)=${OPERATORID})
; passes the call to the application
same =>n,System(${MMAGI}/queue_action.sh action:connect,queue:sales,member_interface:\\”${MEMBERINTERFACE}\\”,member_name:\\”${MEMBERNAME}\\”,cidnum:\\”${CONNECTEDLINE(num)}\\”,cidname:\\”${CONNECTEDLINE(name)}\\”,uniqueid:\\”${MMLINKEDID}\\”,channel:\\”${MMCALLERCHANNEL}\\”)

Asterisk Project Security Advisory – AST-2012-012

Product Asterisk
Summary Asterisk Manager User Unauthorized Shell Access
Nature of Advisory Permission Escalation
Susceptibility Remote Authenticated Sessions
Severity Minor
Exploits Known No
Reported On July 13, 2012
Reported By Zubair Ashraf of IBM X-Force Research
Posted On August 30, 2012
Last Updated On August 30, 2012
Advisory Contact Matt Jordan < mjordan AT digium DOT com >
CVE Name CVE-2012-2186

Description The AMI Originate action can allow a remote user to specify
information that can be used to execute shell commands on
the system hosting Asterisk. This can result in an unwanted
escalation of permissions, as the Originate action, which
requires the “originate” class authorization, can be used
to perform actions that would typically require the
“system” class authorization. Previous attempts to prevent
this permission escalation (AST-2011-006, AST-2012-004)
have sought to do so by inspecting the names of
applications and functions passed in with the Originate
action and, if those applications/functions matched a
predefined set of values, rejecting the command if the user
lacked the “system” class authorization. As reported by IBM
X-Force Research, the “ExternalIVR” application is not
listed in the predefined set of values. The solution for
this particular vulnerability is to include the
“ExternalIVR” application in the set of defined
applications/functions that require “system” class
authorization.

Unfortunately, the approach of inspecting fields in the
Originate action against known applications/functions has a
significant flaw. The predefined set of values can be
bypassed by creative use of the Originate action or by
certain dialplan configurations, which is beyond the
ability of Asterisk to analyze at run-time. Attempting to
work around these scenarios would result in severely
restricting the applications or functions and prevent their
usage for legitimate means. As such, any additional
security vulnerabilities, where an application/function
that would normally require the “system” class
authorization can be executed by users with the “originate”
class authorization, will not be addressed. Instead, the
README-SERIOUSLY.bestpractices.txt file has been updated to
reflect that the AMI Originate action can result in
commands requiring the “system” class authorization to be
executed. Proper system configuration can limit the impact
of such scenarios.

The next release of each version of Asterisk will contain,
in addition to the fix for the “ExternalIVR” application,
an updated README-SERIOUSLY.bestpractices.txt file.

Resolution Asterisk now checks for the “ExternalIVR” application when
processing the Originate action.

Additionally, the README-SERIOUSLY.bestpractices.txt file
has been updated. It is highly recommended that, if AMI is
utilized with accounts that have the “originate” class
authorization, Asterisk is run under a defined user that
does not have root permissions. Accounts with the
“originate” class authorization should be treated in a
similar manner to those with the “system” class
authorization.

Affected Versions
Product Release Series
Asterisk Open Source 1.8.x All versions
Asterisk Open Source 10.x All versions
Certified Asterisk 1.8.11 All versions
Asterisk Digiumphones 10.x.x-digiumphones All versions
Asterisk Business Edition C.3.x All versions

Corrected In
Product Release
Asterisk Open Source 1.8.15.1, 10.7.1
Certified Asterisk 1.8.11-cert6
Asterisk Digiumphones 10.7.1-digiumphones
Asterisk Business Edition C.3.7.6

Patches
SVN URL Revision
http://downloads.asterisk.org/pub/security/AST-2012-012-1.8.diff Asterisk
1.8
http:downloads.asterisk.org/pub/security/AST-2012-012-10.diff Asterisk
10

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

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-012.pdf and
http://downloads.digium.com/pub/security/AST-2012-012.html

Revision History
Date Editor Revisions Made
08/27/2012 Matt Jordan Initial version

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