Protect yourself against future threats.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
===========================================================================
AUSCERT External Security Bulletin Redistribution
ESB-2012.0831
Asterisk Project Security Advisory - AST-2012-012 & AST-2012-013
3 September 2012
===========================================================================
AusCERT Security Bulletin Summary
---------------------------------
Product: Asterisk Open Source
Certified Asterisk
Asterisk Digiumphones
Asterisk Business Edition
Publisher: Asterisk
Operating System: Windows
UNIX variants (UNIX, Linux, OSX)
Impact/Access: Increased Privileges -- Existing Account
Unauthorised Access -- Existing Account
Resolution: Patch/Upgrade
CVE Names: CVE-2012-4737 CVE-2012-2186
Original Bulletin:
http://downloads.digium.com/pub/security/AST-2012-012.html
http://downloads.digium.com/pub/security/AST-2012-013.html
Comment: This bulletin contains two (2) Asterisk security advisories.
- --------------------------BEGIN INCLUDED TEXT--------------------
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.
- -------------------------------------------------------------------------------
Asterisk Project Security Advisory - AST-2012-013
Product Asterisk
Summary ACL rules ignored when placing outbound calls by
certain IAX2 users
Nature of Advisory Unauthorized use of system
Susceptibility Remote Authenticated Sessions
Severity Moderate
Exploits Known None
Reported On 07/27/2012
Reported By Alan Frisch
Posted On 08/30/2012
Last Updated On August 30, 2012
Advisory Contact Matt Jordan < mjordan AT digium DOT com >
CVE Name CVE-2012-4737
Description When an IAX2 call is made using the credentials of a peer
defined in a dynamic Asterisk Realtime Architecture (ARA)
backend, the ACL rules for that peer are not applied to the
call attempt. This allows for a remote attacker who is
aware of a peer's credentials to bypass the ACL rules set
for that peer.
Resolution The ACL rules for peers defined in an ARA backend are now
honored. Users of chan_iax2 should upgrade to the corrected
versions; apply a provided patch; or define their IAX2 peers
outside of an ARA backend in a static configuration file.
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-cert7
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-013.1.8.diff Asterisk
1.8
http://downloads.asterisk.org/pub/security/AST-2012-013.10.diff Asterisk
10
Links https://issues.asterisk.org/jira/browse/ASTERISK-20186
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-013.pdf and
http://downloads.digium.com/pub/security/AST-2012-013.html
Revision History
Date Editor Revisions Made
08/27/2012 Matt Jordan Initial Revision
Asterisk Project Security Advisory - AST-2012-013
Copyright (c) 2012 Digium, Inc. All Rights Reserved.
Permission is hereby granted to distribute and publish this advisory in its
original, unaltered form.
- --------------------------END INCLUDED TEXT--------------------
You have received this e-mail bulletin as a result of your organisation's
registration with AusCERT. The mailing list you are subscribed to is
maintained within your organisation, so if you do not wish to continue
receiving these bulletins you should contact your local IT manager. If
you do not know who that is, please send an email to auscert@auscert.org.au
and we will forward your request to the appropriate person.
NOTE: Third Party Rights
This security bulletin is provided as a service to AusCERT's members. As
AusCERT did not write the document quoted above, AusCERT has had no control
over its content. The decision to follow or act on information or advice
contained in this security bulletin is the responsibility of each user or
organisation, and should be considered in accordance with your organisation's
site policies and procedures. AusCERT takes no responsibility for consequences
which may arise from following or acting on information or advice contained in
this security bulletin.
NOTE: This is only the original release of the security bulletin. It may
not be updated when updates to the original are made. If downloading at
a later date, it is recommended that the bulletin is retrieved directly
from the author's website to ensure that the information is still current.
Contact information for the authors of the original document is included
in the Security Bulletin above. If you have any questions or need further
information, please contact them directly.
Previous advisories and external security bulletins can be retrieved from:
http://www.auscert.org.au/render.html?cid=1980
===========================================================================
Australian Computer Emergency Response Team
The University of Queensland
Brisbane
Qld 4072
Internet Email: auscert@auscert.org.au
Facsimile: (07) 3365 7031
Telephone: (07) 3365 4417 (International: +61 7 3365 4417)
AusCERT personnel answer during Queensland business hours
which are GMT+10:00 (AEST).
On call after hours for member emergencies only.
===========================================================================
-----BEGIN PGP SIGNATURE-----
Comment: http://www.auscert.org.au/render.html?it=1967
iQIVAwUBUEQm7u4yVqjM2NGpAQIZdRAAu1lCYMJ2jo5DlimYbo210v8YFpwIYsz1
lqMgY3GSeOUsC95zaRIABvDuBZVO29Vp3HiZwxNN/OTXHGGNn3BDZ1ZEK9e8QnQW
jYgyeBh1NlN8OTun/+ZU1OJMk9zb2IyFKk2ymxzXcZ8mnlvIMvVae1FRVcpsTEFk
Dr8ogDS9orO0D23lF28upw59tqOlwbJqXUIe+sfQttqy9FawqomGxbs85YhEJNfn
+QysYhtMSS6mntu53Li2C5x5VWoXs4cb6elKqmq2ylnPAwGp36XgTtUm/yqkO3wN
d3jO/ZtxCYlg5hvGSsJnEi73A4rxygzjKjflq1m+M5H7ELSw4VT3YeK6378f9vFV
aHMA3ZdNKA6kfOA/By/ORuCeeeVXhRHOSsBNxGgTA1j2IO4ioJ9DEZh0l+7y7SzU
7qM998xCZB1c1Hr9FQPOE30fDOhPAsj/5qrg75eP5l9cqQMn5sfojDjwiW0WyMXo
LqXo4/G+HNyeTx/sw6EL4CckD/G/1sqa2y2Bh8xv6r1s20K6yc8pwqaUowXAuCYl
kSZ2MGNBAX4R9NPls2ZK7UtirQIwFzouDySj5oXIYcGMRYAyGma49Y1toSIZ2r0K
tAHm2jGzPqxI9WsMnErQ6ufyoObhxXKpE3YgpXkvoMjDJW0ZdpoB0jYpoVoUPJi8
pAfupCNyQhA=
=NXYn
-----END PGP SIGNATURE-----