« Return to Thread: Discussion point: CONSPEC - Context-specific Issues
Re: Patr Traversal and some challenges for CWE
by Pascal Meunier-3
::
Rate this Message:
I don't understand how you would use the sub-nodes, or how they could be
represented. The closest concepts I can think of are an additional
table in a relational database for resources with rows like:
|resource type | name |
|"file type" | "core dump" |
|"file type" | "backup" |
|"file type" | "log" |
or an associative array:
"file type" => ["core dump", "backup", "log"]
"device" => ["tty0"]
etc...
In which case several CWE nodes would have a field that would point to
"file type"? And by editing file types once you would be automatically
updating all the CWE entries that refer to those file types. You could
even have several different lists of file types for different uses.
This would in effect "normalize" the CWE, to use database jargon.
That sounds all good and well if a little complex. I think it's
overkill compared to just adding a field that would support syntax
testing where appropriate.
Nevertheless, I like the idea of avoiding a large number of CWE IDs that
vary on a single, simple detail that could be easily abstracted and
stored in a list. The problem of missing CWE IDs is then reduced to
that of a missing element in the list, which I would think is much less
problematic for someone trying to identify a specific CWE ID relating to
an issue at hand.
Pascal
Steven M. Christey wrote:
> On Wed, 17 Oct 2007, Pascal Meunier wrote:
>
>> I've wondered why a regular expression or grammar couldn't be used
>> sometimes in the CWE, to bring combinatorial explosions under control.
>> Isn't it sufficient, at least for the "pen-test or black-box scanning
>> situation" that the product fails when given one of the possible input
>> instances, and that the testers know how to generate them automatically?
>>
>> It seems to me that it would also work just fine for "general education,
>> as well as characterizing code analysis tool capabilities."
>
> Internally, we've informally discussed "sub-nodes" as one possible
> solution. It's not clear what they would look like, but the basic idea
> is: a CWE node only goes to one particular level. Where greater levels of
> details are desired, "sub-nodes" are created that get attached to the
> higher-level CWE node. These sub-nodes would *not* have their own IDs.
> They would be well-structured in order to support automated processing.
> But, since they would name the specific details, they would still be
> useful in the contexts where that's needed.
>
> Consider a resource-specific example, CWE-538 "File and Directory
> Information Leaks," where it has several child nodes that only differ
> based on which type of file contains the leak: 528 is for core dump files,
> 527 is for CVS repository, 532 is for log files, and 530 is for backup
> files. These are all about the same general resource - files - but only
> vary depending on the *type* of file resource.
>
> There are two things to consider here:
>
> 1) The list of children isn't complete. For example, there's CVS but
> not SVN or other source control products; there's source code but not
> configuration file or data file; there's backup files, but only ~.bk
> is mentioned - how about "~" (Emacs anyone?), .1/.2, .bak, etc.
>
> 2) Path traversal is about files. So, if we decide that we're going to
> split information leak based on different types of files, then why not
> split each path traversal node based on different types of files?
> That would be 12*9 separate nodes (number of children of CWE-23
> times number of children of CWE-538), a total of 108 nodes, just for
> those two.
>
> Now, if 538 were restructured to use "sub-nodes," then it would be at a
> fixed level of abstraction, and the sub-node would list the different
> types of files to consider. This same list of file-types could be reused
> in other CWE nodes that are specific to file resources.
>
> - Steve
>
> P.S. For some other resource-specific examples in CWE, see
> http://cwe.mitre.org/community/research/discussion/resspec.html
represented. The closest concepts I can think of are an additional
table in a relational database for resources with rows like:
|resource type | name |
|"file type" | "core dump" |
|"file type" | "backup" |
|"file type" | "log" |
or an associative array:
"file type" => ["core dump", "backup", "log"]
"device" => ["tty0"]
etc...
In which case several CWE nodes would have a field that would point to
"file type"? And by editing file types once you would be automatically
updating all the CWE entries that refer to those file types. You could
even have several different lists of file types for different uses.
This would in effect "normalize" the CWE, to use database jargon.
That sounds all good and well if a little complex. I think it's
overkill compared to just adding a field that would support syntax
testing where appropriate.
Nevertheless, I like the idea of avoiding a large number of CWE IDs that
vary on a single, simple detail that could be easily abstracted and
stored in a list. The problem of missing CWE IDs is then reduced to
that of a missing element in the list, which I would think is much less
problematic for someone trying to identify a specific CWE ID relating to
an issue at hand.
Pascal
Steven M. Christey wrote:
> On Wed, 17 Oct 2007, Pascal Meunier wrote:
>
>> I've wondered why a regular expression or grammar couldn't be used
>> sometimes in the CWE, to bring combinatorial explosions under control.
>> Isn't it sufficient, at least for the "pen-test or black-box scanning
>> situation" that the product fails when given one of the possible input
>> instances, and that the testers know how to generate them automatically?
>>
>> It seems to me that it would also work just fine for "general education,
>> as well as characterizing code analysis tool capabilities."
>
> Internally, we've informally discussed "sub-nodes" as one possible
> solution. It's not clear what they would look like, but the basic idea
> is: a CWE node only goes to one particular level. Where greater levels of
> details are desired, "sub-nodes" are created that get attached to the
> higher-level CWE node. These sub-nodes would *not* have their own IDs.
> They would be well-structured in order to support automated processing.
> But, since they would name the specific details, they would still be
> useful in the contexts where that's needed.
>
> Consider a resource-specific example, CWE-538 "File and Directory
> Information Leaks," where it has several child nodes that only differ
> based on which type of file contains the leak: 528 is for core dump files,
> 527 is for CVS repository, 532 is for log files, and 530 is for backup
> files. These are all about the same general resource - files - but only
> vary depending on the *type* of file resource.
>
> There are two things to consider here:
>
> 1) The list of children isn't complete. For example, there's CVS but
> not SVN or other source control products; there's source code but not
> configuration file or data file; there's backup files, but only ~.bk
> is mentioned - how about "~" (Emacs anyone?), .1/.2, .bak, etc.
>
> 2) Path traversal is about files. So, if we decide that we're going to
> split information leak based on different types of files, then why not
> split each path traversal node based on different types of files?
> That would be 12*9 separate nodes (number of children of CWE-23
> times number of children of CWE-538), a total of 108 nodes, just for
> those two.
>
> Now, if 538 were restructured to use "sub-nodes," then it would be at a
> fixed level of abstraction, and the sub-node would list the different
> types of files to consider. This same list of file-types could be reused
> in other CWE nodes that are specific to file resources.
>
> - Steve
>
> P.S. For some other resource-specific examples in CWE, see
> http://cwe.mitre.org/community/research/discussion/resspec.html
« Return to Thread: Discussion point: CONSPEC - Context-specific Issues
| Free embeddable forum powered by Nabble | Forum Help |
