On the viewpoint of CWE descriptions

Dear all,

I would like to contribute my two cents into the on-going discussion “Re:Patr Traversal and some challenges for CWE”.

I am assuming that CWE descriptions need to evolve into common, reusable and machine readable content that various TOOLS can leverage in non-trivial ways.

CWEs are complex phenomena, such as a class of software system that has certain common properties. When describing complex phenomena, the community needs to become more aware of the existence of several VIEWPOINTS on the same phenomena. Each of the viewpoints corresponds to a different sub-community of interest, and as a consequence, to different tools. Each viewpoint involves a set of CHARACTERISTICS that are DISCERNABLE by the particular community (in the sense that the community has access to a repository of relevant facts related to the given system under investigation).

In my opinion, there are two major viewpoints for describing software systems and their properties:

-          behavioral view (aka black-box view).

-          code view (aka white-box view)

Behavioral view is about observable events. The Code view is about code patterns (control- and data-flow graphs). I’ll leave it at that for now.

There are more viewpoints, but these two are the major ones. This is a common approach of the Systems Theory (here is a background link to a wikipedia entry: a system is a fundamental concept of systems theory).

When we describe historical events (for example CVE), it is ok to assume the so-called omniscient viewpoint (in which the author knows everything) and provide the facets of description that involve different viewpoints, including the bits of knowledge, non-discernable from either of the two above viewpoints, such as the intentions of the programmer, the requirements for the system, or the weather conditions at a particular phase of the system’s life cycle.

However the value of CWE descriptions as the content for the tools is in their PREDICTIVE POWER. So, we need to select the characteristics that are discernable by a particular community, and describe CWEs as patterns that can be detected by tools. Again, I’ll leave it at that for now.

My observation of the current CWE descriptions is that the viewpoints are often mixed. Path Traversal is likely the best illustration. There are about a dozen different CWEs related to Path Traversal. Their black-box descriptions are quite different, but they all share the same white box code pattern: 1) input data; 2) pass it around; 3) use it to access/manipulate a file resource. From the code viewpoint you DO NOT accept input in the form of “abc\..\..\fgh”, you accept it a byte string (or similar). You can then filter it and narrow down the strings you actually use to access/manipulate your file resource. In fact, the “filter idea” is kind of interesting, because the less you filter, the larger is the class of strings you allow. And if you do not filter at all, you allow any string. So, why there are so many CWEs that are specific to the particular subclass of allowed input strings, e.g. the “abc\..\..\fgh” above ? Well, this is interesting from the black-box viewpoint, penetration testing and such, where we do not deal with ANY string, but with very CONCRETE ones, one at a time. But this is a mix of viewpoints. As the result, the pattern is not really discernable by either tool, which means that extra translation effort is needed in order to make a non-trivial use of such description.

My point is that each viewpoint has its OWN granularity and generality. For the static analysis tools it is important to have sufficient white-box content in CWE descriptions. If you ask me – this should be the foundation for CWE, since it is the code structure that determines the behaviour. If you start with black-box descriptions of the behaviour, we still need to describe the code patterns for the static analysis tools AND PROVE that they correspond to the behaviours we described.

This turned out rather lengthy, but again, under the current exchange rate for Canadian two cents,….

Best regards,

Nikolai Mansourov

Chief Technology Officer

KDM Analytics

cell (613) 276-2323

www.kdmanalytics.com

e-mail: nick@...