Cisco CVE-2022-20968 Validation

A Little Background

Cisco has published a PSIRT/Security Advisory for CVE-2022-20968 relating to a Cisco Discovery Protocol (CDP) Stack Overflow Vulnerability affecting the Cisco 78XX and 88XX series IP Phones. To paraphrase Cisco, there is a vulnerability in the CDP processing feature on the Cisco 78XX and 88XX series phone firmware that could allow unauthenticated attackers to cause a stack overflow.

For full details on the bug summary, please see Cisco’s CVE page.

As for workarounds, there are no workarounds that address the vulnerability. Interestingly, though I would consider this a workaround, Cisco states that a mitigation task that can be used to address the vulnerability is available in the form of disabling CDP and using LLDP if the underlying network equipment support it.

There is firmware TO BE RELEASED in January 2023 – firmware 14.2(1). Should you undertake the workaround steps with a firmware fix on the horizon in 2-6 weeks time? Maybe. That’s for you to determine. But how can you quickly identify if you’re affected, which phones are affected, and how many phones you’ll need to upgrade when the fix is released? Keep reading.

Checking If You’re Affected

There’s a few ways to check if you’re affected by this Security Advisory. The most manual way of accomplishing this is to pull up the CUCM GUI and search under Device > Phone by Device Type for “contains” Cisco 78, and again for Cisco 88. The search results will give you a total count of 88xx series phone and 7xx series phones, but with multiple pages and copy/pasting out of a web browser it can be annoying, especially if you have multiple clusters to check. Another drawback is that it doesn’t break the results down by models within the series, unless you search accordingly. This increases your search count and the time it takes to perform validation steps.

Checking Faster With SQL

One way to perform these validations faster with one command on the Publisher node of each cluster is an SQL query. We can run this directly in the CLI and look for the return. I’ve built out a suitable query, though it’s a little much for the current situation. I leave in the extra data pulls for this query as it also returns the current Default Firmware for the device model. The query also includes whether the phone is SIP (11) or SCCP (0), if there are different protocols being used in the environment for some models.

The Query:

run sql select count(d.tkmodel), tp.name as phonemodel, defaults.tkdeviceprotocol as protocol, defaults.loadinformation as defaultfw from device as d inner join typeproduct as tp on d.tkmodel=tp.tkmodel inner join defaults on tp.tkmodel=defaults.tkmodel where d.name like '%' and defaults.loadinformation != "" and tp.name like 'Cisco 78%' or tp.name like 'Cisco 88%' group by d.tkmodel, tp.name, defaults.loadinformation, defaults.tkdeviceprotocol

If your query was successful, and there are applicable phone models configured in your cluster you’ll get something like what we see below. It’s pretty self-explanatory, but from left to right PER ROW we have: Device Count (how many phones), Phone Model (what phone model), Protocol (SCCP = 0, SIP = 11), and Default Firmware (what is the default firmware configured for this device type).

The Return:

(count) phonemodel protocol defaultfw
======= ========== ======== ==========================
5       Cisco 8861 11       sip88xx.12-8-1-0101-482
81      Cisco 8851 11       sip88xx.12-8-1-0101-482
4       Cisco 8841 11       sip88xx.12-8-1-0101-482
2       Cisco 7832 11       sip7832.12-8-1-0101-482
5       Cisco 8831 11       sip8831.10-3-1SR6-4-NA
1       Cisco 8845 11       sip8845_65.12-8-1-0101-482
1       Cisco 7821 11       sip78xx.12-8-1-0101-482
1       Cisco 8865 11       sip8845_65.12-8-1-0101-482
1       Cisco 8821 11       sip8821.11-0-6-7
1       Cisco 7861 11       sip78xx.12-8-1-0101-482

With this information you can confirm whether you are affected, what models you’re using that are affected, and what firmware is the device default. This does not account for one-off phones using a static firmware load. To identify those phones please refer to my post here. These phones will need their phone load blanked once the new firmware is installed and set as the default firmware load for the given phone model.

From here you can keep an eye on the PSIRT and Bug ID listed within for updated information, and check Cisco’s download center for the firmware when it releases.

Now, I wouldn’t be me if I didn’t try to make a script for this. But I’m me, so I did.

The Python Script Method

Now, I wouldn’t call this faster on my end as it took about two hours to come up with the proper query, cobble together some code to send an SQL query over AXL on the CUCM Publisher, and find a (so far) reliable way to determine if any valid data was returned to us in the SOAP message response as an “affected/not affected” check. If my script doesn’t find an affected phone model it will still prompt the user to manually validate whether there are 88XX or 78XX phones configured in CUCM… just to be safe.

I tried to keep the script from storing any data in temp files as I’ve used it as a crutch for a while. Instead, we take the SOAP response from CUCM, feed it into the python minidom XML module to turn it into a pretty XML string, then parse that XML string to find ‘rows’. After a few layers of SOAP XML headers we have “return” tags, and nested inside are “row” tags. One row tag per device model returned, with phone model, count, default firmware and protocol tags and associated data nestled deep inside. If there are no “rows” tags within return it is considered that the system is not affected as the SQL query did not return any concerning rows of data. Otherwise, it parses over the data and reports it back to the shell and advises the user to visit the PSIRT site for additional detail.

To look over, download, and/or test the script please visit my GitHub, with a direct link to the script here. In the event the script moves in the future, please check the base GitHub repo.

For any issues with the script, exceptions hit or instances where it does not catch phone models it should, please submit an issue against the GitHub and feel free to notify me on our Discord server under the #improvements-requests chat channel. The Discord and GitHub links are available in the side navigation panel.

That’s it from me, I hope you all have a wonderful day and the best of luck with your future firmware upgrades to fix this bug!