Understanding: Affected but Not Vulnerable

Jan 06, 2018
3 minutes
25 views

Palo Alto Networks Product Security Incident Response Team (PSIRT) investigates and responds to reports of possible vulnerabilities in Palo Alto Networks products and services. The PSIRT thoroughly investigates all reports and at the conclusion of the investigation, takes the appropriate action to protect customers. Investigating vulnerabilities is not just understanding if a piece of vulnerable code is present on the system, but determining if it actually exposes an exploitable, attackable vulnerability. Practically speaking: does the code actually enable someone to carry out an attack that can compromise the confidentiality, integrity and/or availability of the system? Or is the code on the system but effectively inert, unable to be used by itself to cause a compromise?

People generally have a one-to-one association between vulnerable code and the ability to use it to carry out an attack. But not every instance of vulnerable code results in a viable attack that can compromise the confidentiality, integrity and/or availability of the system. There can be specific circumstances that limit the scope or mitigate exposure of the vulnerable code in such a way that make it not viable in practical terms for an attack.

One of the key things in investigating a vulnerability report is not just determining if vulnerable code is present on the system, but if it’s actually implemented in a way that exposes an exploitable, attackable vulnerability.

Sometimes a Palo Alto Networks PSIRT investigation will find that vulnerable code is on the system but doesn’t expose an exploitable, attackable vulnerability.

An example of this is a vulnerability in PAN-OS that would require an attacker to load and execute code locally on the system for a successful attack. By design, only users who have system-level access can load and run code on PAN-OS. Any code they run would have complete access to the system and therefore running code that attacks a vulnerability in this case would be pointless. This gives the would-be attacker nothing that she or he doesn’t already have: complete access to the system.

This is an instance that we term “affected but not vulnerable.” The vulnerable code is present on the system, but the specifics around it don’t negatively impact the security of the system.

This is a scenario that we find around open source vulnerabilities in particular. In many cases we will find that a vulnerability in the open source code is present, but there are no viable attack vectors to it.

In the case of “affected but not vulnerable,” the Palo Alto Networks PSIRT may decide the best remedy for the vulnerable code isn’t a security update, a change that addresses the vulnerable code in some other way, such as the next version of software.

A factor in this determination is the risk assessment that balances the security risk of the vulnerable code with the instability risk that is inherent in a change in code. In this case, it’s a non-existent security risk balanced against some real risk (whose severity depends on the code change).

The Palo Alto Networks PSIRT thoroughly investigates all reports and has a high degree of confidence when concluding that something is affected, but not vulnerable. Vulnerability research is a fluid field and subject to re-evaluation should new information emerge that could then result in new conclusions and appropriate remedies.


Subscribe to the Newsletter!

Sign up to receive must-read articles, Playbooks of the Week, new feature announcements, and more.