Skip to content
Snippets Groups Projects
  • Matthew Jordan's avatar
    d624f2c5
    AST-2012-012: Resolve AMI User Unauthorized Shell Access through ExternalIVR · d624f2c5
    Matthew Jordan authored
    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 noted 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
    ........
    
    Merged revisions 371999 from http://svn.asterisk.org/svn/asterisk/branches/10
    ........
    
    Merged revisions 372000 from http://svn.asterisk.org/svn/asterisk/branches/11
    
    
    git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372001 65c4cc65-6c06-0410-ace0-fbb531ad65f3
    d624f2c5
    History
    AST-2012-012: Resolve AMI User Unauthorized Shell Access through ExternalIVR
    Matthew Jordan authored
    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 noted 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
    ........
    
    Merged revisions 371999 from http://svn.asterisk.org/svn/asterisk/branches/10
    ........
    
    Merged revisions 372000 from http://svn.asterisk.org/svn/asterisk/branches/11
    
    
    git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372001 65c4cc65-6c06-0410-ace0-fbb531ad65f3