Making the Vulnerability Disclosure ‘Nice’ List: Cisco
December 23, 2019 • RBS
Risk Based Security has always made it a point to praise organizations that operate in good faith and Cisco’s PSIRT team definitely knocked it out of the park this month. It is vital that vulnerability databases are treated as living entities, where policies are continually reviewed and entries are updated for clarity, quality, and new information. This operating concept is vital, and demonstrated succinctly in a recent dealing with Cisco where we found conflicting information within their formal advisories and their Cisco Support Community (CSC) bug reports. While our VulnDB team had a standing policy on processing information from Cisco, we used it as a chance to review that policy as well as gain clarity on the accuracy of their resources.
In most situations, organizations, including RBS, rely on Cisco’s formal advisories as the single source of truth for official vulnerability information in Cisco products. Our research team had noticed some confusing and seemingly unnecessary information disclosed via CSCs, which could result in users performing unneeded work in attempts to remediate a vulnerability that doesn’t impact them.
The prompt response and generous discussion by Cisco’s PSIRT team both confirmed this and, although we will maintain our current policy, this exchange led to a small change in version coverage within VulnDB. Our communications with Cisco, and the resulting information, are provided below.
On the Value and Accuracy of Cisco’s Advisories vs CSCs
On May 5th, 2019, Cisco published an advisory for a vulnerability in Cisco Adaptive Security Appliance (ASA) and Cisco Firepower Threat Defense (FTD) software. Toward the bottom of the advisory, a chart lists the affected ASA release tree, recommended release for this vulnerability as a fixing version, and the recommended release for all vulnerabilities in the advisory. (In this advisory, please note that the 9.7 train is listed as vulnerable with the fix being an upgrade to version 9.8.4.)
The corresponding CSC (CSCvj33780) provides a longer list of fixing versions in the “Known Fixed Releases” section, including 9.7(1.26):
This shows a clear discrepancy between the formal advisory and the associated CSC. The advisory strongly implies that all versions of the 9.7 train are affected, while the CSC suggests there is a specific fixing version in that train. On the surface, the CSC bug report may seem as a better source of information given that it has more information, but in reality, this is not the case. After reaching out to Cisco PSIRT, they confirmed that 9.7(1.26) should not be considered a fixing version. How could that be?
Cisco PSIRT went on to clarify that the CSCs include information from the development teams that do not reflect what software is actually released to customers. In this case, they indicated that 9.7.(1.26) was used to check-in the fix to the 9.7 train, but it was done to ensure that subsequent trains received the fix. This is how a CSC may list a number of builds listed in the defect that show a fixing version, but in reality were never available to customers and cannot be considered a fixing version.
Another concern in this CSC is that among the fixing versions listed are ones in the 96, 98, 99, 100, 101, and 201 trains. The Cisco ASA roadmap clearly shows that no such trains officially exist. We questioned Cisco about these trains and they elaborated on their automation tasks on the developer side, saying that these may represent future releases that are internal builds in early development, but have not been made public in any fashion. If an organization took this information and attempted to remediate, the absence of explanation would be likely to create unnecessary confusion.
Another issue we see in Cisco Security Advisories is that occasionally they do not list all specific vulnerable versions, rather just an affected train (e.g. 9.8) and the first fixed version next to it (e.g. 98.3(0.6)). In cases where a vendor does not expressly list vulnerable versions or a range (or just states “all prior versions” without actually having verified it), it is RBS policy for the VulnDB team to only include the fixed version and latest vulnerable version. Only versions known to be affected are included to ensure accurate VulnDB entries, although customers are generally encouraged to consider prior versions as likely affected.
Other sources like NVD and BID often include prior versions without actually knowing if these are vulnerable, and in some of these cases, RBS has confirmed that some of the listed versions are actually not vulnerable. This may happen when a new feature is introduced in e.g. version 5.0, but they list all prior versions including 1.x, 2.x, 3.x, and 4.x, despite not having the vulnerable functionality.
As a result, RBS has historically not added the whole train as affected but initially just the train itself and later also the latest vulnerable version. However, Cisco PSIRT has clarified that if nothing else is stated, it is safe to conclude that all versions in a train are vulnerable, saying that if a vulnerability “were introduced within a build this would be noted in the advisory.” This is a great case where not all vendor advisories can be treated equal and emphasizes the value of a vulnerability database team reaching out to vendors and enjoying a collaborative effort.
The Cisco PSIRT team really went out of their way on this one and Risk Based Security wants to recognize that, and thank them for taking the time that they did. In today’s environment, organizations tend to unintentionally marginalize their PSIRT and security teams by basing their primary metrics on “how many tickets did you answer” or “what is the future RoI”. However, as we all know, it’s not just about the tickets or vulnerabilities fielded; it can be just as much about adding clarity to disclosure processes that greatly assist mutual customers.
In some organizations PSIRT and security teams fall into a security ‘catch-22’ where a successful job means no breaches. Unfortunately, having no breaches may create the perception that there is less need for the security team. Then, if a breach occurs, the knee-jerk reaction of “Breach? Hire more security!” starts the cycle once again.
Thanks again to the team at Cisco. We look forward to future collaborative efforts. Happy holidays!