Merged revisions 371999,372020 via svnmerge from

Merged revisions 371999,372020 via svnmerge from
file:///srv/subversion/repos/asterisk/branches/10

................
  r371999 | mjordan | 2012-08-30 11:06:47 -0500 (Thu, 30 Aug 2012) | 36 lines

  AST-2012-012: Resolve AMI User Unauthorized Shell Access through ExternalIVR

  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.

  (closes issue ASTERISK-20132)
  Reported by: Zubair Ashraf of IBM X-Force Research
  ........

  Merged revisions 371998 from http://svn.asterisk.org/svn/asterisk/branches/1.8
................
  r372020 | mjordan | 2012-08-30 11:22:54 -0500 (Thu, 30 Aug 2012) | 17 lines

  AST-2012-013: Resolve ACL rules being ignored during calls by some IAX2 peers

  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.

  This patch ensures that the ACLs are applied for all peers, regardless of their
  storage mechanism.

  (closes issue ASTERISK-20186)
  Reported by: Alan Frisch
  Tested by: mjordan, Alan Frisch
  ........

  Merged revisions 372015 from http://svn.asterisk.org/svn/asterisk/branches/1.8
................

git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10-digiumphones@372027 65c4cc65-6c06-0410-ace0-fbb531ad65f3