Cisco IP Phones Buffer Overflow and Denial of Service Vulnerabilities

Multiple vulnerabilities in the Cisco Discovery Protocol and Link Layer Discovery Protocol (LLDP) implementations for Cisco IP Phone Series 68xx/78xx/88xx could allow an unauthenticated, adjacent attacker to execute code remotely or cause a reload of an affected IP phone.

These vulnerabilities are due to missing checks when the IP phone processes a Cisco Discovery Protocol or LLDP packet. An attacker could exploit these vulnerabilities by sending a malicious Cisco Discovery Protocol or LLDP packet to the targeted IP phone. A successful exploit could allow the attacker to execute code on the affected IP phone or cause it to reload unexpectedly, resulting in a denial of service (DoS) condition.

Note: Cisco Discovery Protocol is a Layer 2 protocol. To exploit these vulnerabilities, an attacker must be in the same broadcast domain as the affected device (Layer 2 adjacent).

Cisco has released software updates that address these vulnerabilities. There are no workarounds that address these vulnerabilities.

This advisory is available at the following link:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ipphone-rce-dos-U2PsSkz3

Security Impact Rating: Medium

CVE: CVE-2021-1379

Related:

  • No Related Posts

Cisco Nexus 9000 Series Fabric Switches ACI Mode Link Layer Discovery Protocol Port Denial of Service Vulnerability

A vulnerability in the Link Layer Discovery Protocol (LLDP) for Nexus 9000 Series Fabric Switches in Application Centric Infrastructure (ACI) mode could allow an unauthenticated, adjacent attacker to disable switching on a small form-factor pluggable (SFP) interface.

This vulnerability is due to incomplete validation of the source of a received LLDP packet. An attacker could exploit this vulnerability by sending a crafted LLDP packet on an SFP interface to an affected device. A successful exploit could allow the attacker to disable switching on the SFP interface, which could disrupt network traffic.

Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.

This advisory is available at the following link:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-apic-lldap-dos-WerV9CFj

Security Impact Rating: Medium

CVE: CVE-2021-1231

Related:

  • No Related Posts

Cisco NX-OS Software ICMP Version 6 Memory Leak Denial of Service Vulnerability

A vulnerability in ICMP Version 6 (ICMPv6) processing in Cisco NX-OS Software could allow an unauthenticated, remote attacker to cause a slow system memory leak, which over time could lead to a denial of service (DoS) condition.

This vulnerability is due to improper error handling when an IPv6-configured interface receives a specific type of ICMPv6 packet. An attacker could exploit this vulnerability by sending a sustained rate of crafted ICMPv6 packets to a local IPv6 address on a targeted device. A successful exploit could allow the attacker to cause a system memory leak in the ICMPv6 process on the device. As a result, the ICMPv6 process could run out of system memory and stop processing traffic. The device could then drop all ICMPv6 packets, causing traffic instability on the device. Restoring device functionality would require a device reboot.

Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.

This advisory is available at the following link:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-fxos-nxos-icmpv6-dos-YD55jVCq

Security Impact Rating: Medium

CVE: CVE-2021-1229

Related:

  • No Related Posts

Unable to use TLS/SSL LDAP Auth after ADM upgrade to latest build 13.0-71.40 – TLS Handshake fails with “Unknown CA”

Permanent fix provided in next build ADM 13.0-76.xx and above.

Workaround ::

=====================

Execute one of these commands in ADM CLI to overwrite Certificate attribute retrieval faulty code. Customers can keep the existing LDAP Settings, no need to change anything. External authentication should work correctly now over SSL/TLS Security.

For SSL

LDAPTLS_REQCERT=never ldapsearch -D CN=[service_account],CN=users,DC=lab,DC=com -H ldaps://[ldap_ip]:636 -b DC=lab,DC=com -Z -A -o nettimeout=3 -w [passwd]

For TLS

LDAPTLS_REQCERT=never ldapsearch -D CN=[service_account],CN=users,DC=lab,DC=com -H ldap://[ldap_ip]:389 -b DC=lab,DC=com -Z -A -o nettimeout=3 -w [passwd]

Customers can safely proceed and configure LDAP server with security type TLS/SSL. There wouldn’t be any impact.

Related:

  • No Related Posts

Unable to use TLS/SSL LDAP Auth after ADM upgrade to latest build 13.0-71.40 – TLS Handshake fails with “Unknown CA”

Permanent fix provided in next build ADM 13.0-76.xx and above.

Workaround ::

=====================

Execute one of these commands in ADM CLI to overwrite Certificate attribute retrieval faulty code. Customers can keep the existing LDAP Settings, no need to change anything. External authentication should work correctly now over SSL/TLS Security.

For SSL

LDAPTLS_REQCERT=never ldapsearch -D CN=[service_account],CN=users,DC=lab,DC=com -H ldaps://[ldap_ip]:636 -b DC=lab,DC=com -A -o nettimeout=3 -w [passwd]

For TLS

LDAPTLS_REQCERT=never ldapsearch -D CN=[service_account],CN=users,DC=lab,DC=com -H ldap://[ldap_ip]:389 -b DC=lab,DC=com -Z -A -o nettimeout=3 -w [passwd]

To tailor the commands to any specific needs based on LDAP config, do from CLI “ldapsearch -?” for complete command details.

Options used

===========

ldapsearch is FreeBSD built-in command

-D binddn : bind DN

-H URI : LDAP Uniform Resource Identifier(s)

-b basedn : base dn for search

-Z : Start TLS request (-ZZ to require successful response)

-A : retrieve attribute names only (no values)

-o <opt>[=<optparam>] : general options

-w password

Customers can safely proceed and configure LDAP server with security type TLS/SSL. There wouldn’t be any impact.

Related:

  • No Related Posts

Unable to use TLS/SSL LDAP Auth after ADM upgrade to latest build 13.0-71.40 – TLS Handshake fails with “Unknown CA”

Permanent fix provided in next build ADM 13.0-76.xx and above.

Workaround ::

=====================

Execute one of these commands in ADM CLI to overwrite Certificate attribute retrieval faulty code. Customers can keep the existing LDAP Settings, no need to change anything. External authentication should work correctly now over SSL/TLS Security.

For SSL

LDAPTLS_REQCERT=never ldapsearch -D CN=[service_account],CN=users,DC=lab,DC=com -H ldaps://[ldap_ip]:636 -b DC=lab,DC=com -A -o nettimeout=3 -w [passwd]

For TLS

LDAPTLS_REQCERT=never ldapsearch -D CN=[service_account],CN=users,DC=lab,DC=com -H ldap://[ldap_ip]:389 -b DC=lab,DC=com -Z -A -o nettimeout=3 -w [passwd]

To tailor the commands to any specific needs based on LDAP config, do from CLI “ldapsearch -?” for complete command details.

Options used

===========

ldapsearch is FreeBSD built-in command

-D binddn : bind DN

-H URI : LDAP Uniform Resource Identifier(s)

-b basedn : base dn for search

-Z : Start TLS request (-ZZ to require successful response)

-A : retrieve attribute names only (no values)

-o <opt>[=<optparam>] : general options

-w password

Customers can safely proceed and configure LDAP server with security type TLS/SSL. There wouldn’t be any impact.

Related:

  • No Related Posts

Unable to use TLS/SSL LDAP Auth after ADM upgrade to latest build 13.0-71.40 – TLS Handshake fails with “Unknown CA”

Permanent fix provided in next build ADM 13.0-76.xx and above.

Workaround ::

=====================

Execute one of these commands in ADM CLI to overwrite Certificate attribute retrieval faulty code. Customers can keep the existing LDAP Settings, no need to change anything. External authentication should work correctly now over SSL/TLS Security.

For SSL

LDAPTLS_REQCERT=never ldapsearch -D CN=[service_account],CN=users,DC=lab,DC=com -H ldaps://[ldap_ip]:636 -b DC=lab,DC=com -A -o nettimeout=3 -w [passwd]

For TLS

LDAPTLS_REQCERT=never ldapsearch -D CN=[service_account],CN=users,DC=lab,DC=com -H ldap://[ldap_ip]:389 -b DC=lab,DC=com -Z -A -o nettimeout=3 -w [passwd]

To tailor the commands to any specific needs based on LDAP config, do from CLI “ldapsearch -?” for complete command details.

Options used

===========

ldapsearch is FreeBSD built-in command

-D binddn : bind DN

-H URI : LDAP Uniform Resource Identifier(s)

-b basedn : base dn for search

-Z : Start TLS request (-ZZ to require successful response)

-A : retrieve attribute names only (no values)

-o <opt>[=<optparam>] : general options

-w password

Customers can safely proceed and configure LDAP server with security type TLS/SSL. There wouldn’t be any impact.

Related:

  • No Related Posts

Unable to use TLS/SSL LDAP Auth after ADM upgrade to latest build 13.0-71.40 – TLS Handshake fails with “Unknown CA”

Permanent fix provided in next build ADM 13.0-76.xx and above.

Workaround ::

=====================

Execute one of these commands in ADM CLI to overwrite Certificate attribute retrieval faulty code. Customers can keep the existing LDAP Settings, no need to change anything. External authentication should work correctly now over SSL/TLS Security.

For SSL

LDAPTLS_REQCERT=never ldapsearch -D CN=[service_account],CN=users,DC=lab,DC=com -H ldaps://[ldap_ip]:636 -b DC=lab,DC=com -A -o nettimeout=3 -w [passwd]

For TLS

LDAPTLS_REQCERT=never ldapsearch -D CN=[service_account],CN=users,DC=lab,DC=com -H ldap://[ldap_ip]:389 -b DC=lab,DC=com -Z -A -o nettimeout=3 -w [passwd]

To tailor the commands to any specific needs based on LDAP config, do from CLI “ldapsearch -?” for complete command details.

Options used

===========

ldapsearch is FreeBSD built-in command

-D binddn : bind DN

-H URI : LDAP Uniform Resource Identifier(s)

-b basedn : base dn for search

-Z : Start TLS request (-ZZ to require successful response)

-A : retrieve attribute names only (no values)

-o <opt>[=<optparam>] : general options

-w password

Customers can safely proceed and configure LDAP server with security type TLS/SSL. There wouldn’t be any impact.

Related:

  • No Related Posts

Unable to use TLS/SSL LDAP Auth after ADM upgrade to latest build 13.0-71.40 – TLS Handshake fails with “Unknown CA”

Permanent fix provided in next build ADM 13.0-76.xx and above.

Workaround ::

=====================

Execute one of these commands in ADM CLI to overwrite Certificate attribute retrieval faulty code. Customers can keep the existing LDAP Settings, no need to change anything. External authentication should work correctly now over SSL/TLS Security.

For SSL

LDAPTLS_REQCERT=never ldapsearch -D CN=[service_account],CN=users,DC=lab,DC=com -H ldaps://[ldap_ip]:636 -b DC=lab,DC=com -A -o nettimeout=3 -w [passwd]

For TLS

LDAPTLS_REQCERT=never ldapsearch -D CN=[service_account],CN=users,DC=lab,DC=com -H ldap://[ldap_ip]:389 -b DC=lab,DC=com -Z -A -o nettimeout=3 -w [passwd]

To tailor the commands to any specific needs based on LDAP config, do from CLI “ldapsearch -?” for complete command details.

Options used

===========

ldapsearch is FreeBSD built-in command

-D binddn : bind DN

-H URI : LDAP Uniform Resource Identifier(s)

-b basedn : base dn for search

-Z : Start TLS request (-ZZ to require successful response)

-A : retrieve attribute names only (no values)

-o <opt>[=<optparam>] : general options

-w password

Customers can safely proceed and configure LDAP server with security type TLS/SSL. There wouldn’t be any impact.

Related:

  • No Related Posts

Unable to use TLS/SSL LDAP Auth after ADM upgrade to latest build 13.0-71.40 – TLS Handshake fails with “Unknown CA”

Permanent fix provided in next build ADM 13.0-76.xx and above.

Workaround ::

=====================

Execute one of these commands in ADM CLI to overwrite Certificate attribute retrieval faulty code. Customers can keep the existing LDAP Settings, no need to change anything. External authentication should work correctly now over SSL/TLS Security.

For SSL

LDAPTLS_REQCERT=never ldapsearch -D CN=[service_account],CN=users,DC=lab,DC=com -H ldaps://[ldap_ip]:636 -b DC=lab,DC=com -Z -A -o nettimeout=3 -w [passwd]

For TLS

LDAPTLS_REQCERT=never ldapsearch -D CN=[service_account],CN=users,DC=lab,DC=com -H ldap://[ldap_ip]:389 -b DC=lab,DC=com -Z -A -o nettimeout=3 -w [passwd]

Customers can safely proceed and configure LDAP server with security type TLS/SSL. There wouldn’t be any impact.

Related:

  • No Related Posts