Guest

Preview Tool

Cisco Bug: CSCur00511 - ACS evaluation for CVE-2014-6271 and CVE-2014-7169

Last Modified

Jan 30, 2016

Products (1)

  • Cisco Secure Access Control Server Solution Engine

Known Affected Releases

5.4(0.46) 5.5(0.46) 5.6(0.22)

Description (partial)

The Cisco Secure Access Control Server (ACS) includes a version of bash that is affected by the vulnerabilities
identified by the Common Vulnerability and Exposures (CVE) IDs:

CVE-2014-6271
CVE-2014-7169

This bug has been opened to address the potential impact on this product.
Analysis from development team:
All shipping versions of ACS are vulnerable CVE-2014-6271, CVE-2014-7169,  CVE-2014-7186, CVE-2014-7187 , CVE-2014-6277 and CVE-2014-6278 (AKA ShellShock bug). ACS patch will be made available for all supported versions of ACS in a timely manner.  That said, the exposure of this bug in ACS is very limited.  The shellshock vulnerability allows an SSH AUTHENTICATED user run a generic Linux command.   The key word being 'AUTHENTICATED'.  Hence if an attacker does not have the username and password of an ACS CLI user, they will not  be able to exploit this vulnerability on ACS. 

If the user DOES have credentials, and would like to exploit the shellshock, that CLI user would be able to run generic Linux commands on the ACS Server that would normally not be able to run (Because the ACS CLI does not expose generic Linux commands).  However those Linux commands will run as the logged in CLI user account, not as the Linux root user.  Hence, this limits exposure of the vulnerability in ACS.  An example of an exploit using shellshock in ACS would be to view Linux system files they would normally not be able to view. 

The workaround to remove the vulnerability would be to disable the SSH daemon via the following CLI, then reload the ACS server to ensure all  SSH sessions have been terminated.  The following CLI demonstrates how to to disable SSH service and reload the node:

---snip
acs1/admin# configure terminal
acs1/admin(config)# no service sshd enable 
acs1/admin(config)# end
acs1/admin# reload
Save the current ADE-OS running configuration? (yes/no) [yes] ? yes
Continue with reboot? [y/n] y
---snip


Disable SSH as follows (until the ACS patch with the fix for CSCur00511 is installed):

---snip
acs1/admin# configure terminal
acs1/admin(config)# no service sshd enable 
acs1/admin(config)# end
acs1/admin# reload
Save the current ADE-OS running configuration? (yes/no) [yes] ? yes
Continue with reboot? [y/n] y
---snip


The other work around  can be restrict IP addresses to access CLI of ACS only for known admin laptops by making configuration change on end switch /firewall device where ACS is connected .

For example: 
tcp permit <trusted segment> <ACS hosts> eq 22 
tcp deny any <acs> eq 22 
permit rest   




The Cisco Secure Access Control Server (ACS) includes a version of bash that is affected by the vulnerabilities
identified by the Common Vulnerability and Exposures (CVE) IDs:

CVE-2014-6271
CVE-2014-7169

This bug has been opened to address the potential impact on this product.
Analysis from development team:
All shipping versions of ACS are vulnerable CVE-2014-6271, CVE-2014-7169,  CVE-2014-7186, CVE-2014-7187 , CVE-2014-6277 and CVE-2014-6278 (AKA ShellShock bug). ACS patch will be made available for all supported versions of ACS in a timely manner.  That said, the exposure of this bug in ACS is very limited.  The shellshock vulnerability allows an SSH AUTHENTICATED user run a generic Linux command.   The key word being 'AUTHENTICATED'.  Hence if an attacker does not have the username and password of an ACS CLI user, they will not  be able to exploit this vulnerability on ACS. 

If the user DOES have credentials, and would like to exploit the shellshock, that CLI user would be able to run generic Linux commands on the ACS Server that would normally not be able to run (Because the ACS CLI does not expose generic Linux commands).  However those Linux commands will run as the logged in CLI user account, not as the Linux root user.  Hence, this limits exposure of the vulnerability in ACS.  An example of an exploit using shellshock in ACS would be to view Linux system files they would normally not be able to view. 

The workaround to remove the vulnerability would be to disable the SSH daemon via the following CLI, then reload the ACS server to ensure all  SSH sessions have been terminated.  The following CLI demonstrates how to to disable SSH service and reload the node:

---snip
acs1/admin# configure terminal
acs1/admin(config)# no service sshd enable 
acs1/admin(config)# end
acs1/admin# reload
Save the current ADE-OS running configuration? (yes/no) [yes] ? yes
Continue with reboot? [y/n] y
---snip


Disable SSH as follows (until the ACS patch with the fix for CSCur00511 is installed):

---snip
acs1/admin# configure terminal
acs1/admin(config)# no service sshd enable 
acs1/admin(config)# end
acs1/admin# reload
Save the current ADE-OS running configuration? (yes/no) [yes] ? yes
Continue with reboot? [y/n] y
---snip


The other work around  can be restrict IP addresses to access CLI of ACS only for known admin laptops by making configuration change on end switch /firewall device where ACS is connected .

For example: 
tcp permit <trusted segment> <ACS hosts> eq 22 
tcp deny any <acs> eq 22 
permit rest

Symptom:
The Cisco Secure Access Control Server (ACS) includes a version of bash that is affected by the vulnerabilities
identified by the Common Vulnerability and Exposures (CVE) IDs:

CVE-2014-6271
CVE-2014-7169

This bug has been opened to address the potential impact on this product.
Analysis from development team:
All shipping versions of ACS are vulnerable CVE-2014-6271, CVE-2014-7169,  CVE-2014-7186, CVE-2014-7187 , CVE-2014-6277 and CVE-2014-6278 (AKA ShellShock bug). ACS patch will be made available for all supported versions of ACS in a timely manner.  That said, the exposure of this bug in ACS is very limited.  The shellshock vulnerability allows an SSH AUTHENTICATED user run a generic Linux command.   The key word being 'AUTHENTICATED'.  Hence if an attacker does not have the username and password of an ACS CLI user, they will not  be able to exploit this vulnerability on ACS. 

If the user DOES have credentials, and would like to exploit the shellshock, that CLI user would be able to run generic Linux commands on the ACS Server that would normally not be able to run (Because the ACS CLI does not expose generic Linux commands).  However those Linux commands will run as the logged in CLI user account, not as the Linux root user.  Hence, this limits exposure of the vulnerability in ACS.  An example of an exploit using shellshock in ACS would be to view Linux system files they would normally not be able to view. 

The workaround to remove the vulnerability would be to disable the SSH daemon via the following CLI, then reload the ACS server to ensure all  SSH sessions have been terminated.  The following CLI demonstrates how to to disable SSH service and reload the node:

---snip
acs1/admin# configure terminal
acs1/admin(config)# no service sshd enable 
acs1/admin(config)# end
acs1/admin# reload
Save the current ADE-OS running configuration? (yes/no) [yes] ? yes
Continue with reboot? [y/n] y
---snip

Conditions:

ACS server is exposed to this vulnerability only if they have ssh service enabled.  If SSH is enabled, a remote user with ACS CLI credentials will be able to exploit the vulnerability and run generic Linux commands.

Bug details contain sensitive information and therefore require a Cisco.com account to be viewed.

Bug Details Include

  • Full Description (including symptoms, conditions and workarounds)
  • Status
  • Severity
  • Known Fixed Releases
  • Related Community Discussions
  • Number of Related Support Cases
Bug information is viewable for customers and partners who have a service contract. Registered users can view up to 200 bugs per month without a service contract.