« Return to Thread: Discussion point: CONSPEC - Context-specific Issues
Re: Patr Traversal and some challenges for CWE
by Dave McKinney
::
Rate this Message:
On Wed, Oct 17, 2007 at 01:44:39PM -0400, Steven M. Christey wrote:
> > As a more general comment--have you given any thought to collapsing some
> > of these together? There seem to be an awful lot of nuanced
> > distinctions. For example, if you were to introduce the term "separator
> > character" which could be equal to '\' or '/' you could quickly
> > eliminate a number of leafs in this section.
>
> We've done a little bit of thinking on this. The path traversal nodes are
> one part of the tree that seems excessively deep.
>
> Note that the current path traversal leaves, such as "..." and "....//",
> are all attack-focused. They concentrate on specific manipulations that
> are nonetheless a little different from each other.
Supporting the attack-focused variants as individual nodes is where
the problem lies I think. I don't see this very often in other parts of the CWE,
where it is often adequate to generalize the issue and then
split-hairs at a higher level than what is being done with 'Absolute'
and 'Relative' Path Traversal.
These variants are either because the OS/filesystem/shell supports
different permutations of path traversal syntax or possibly because
there have been common instances in the wild where an application's
input validation routines have opened the door for new path traversal
variants (in an honest effort to prevent simpler variants). Couldn't
the common cases be described in the context notes without meriting
their own nodes?
Do the variants represent distinct manifestations of a larger problem
or are they just more ways to skin the same cat? I understand there is
a need for both pen-testers and application developers to be aware of
these variants but to me it seems inconsistent with how other CWE
entries have been generalized. For example, if you look at OS Command
Injection as a somewhat similar problem, it does not have child nodes
that reflect specific metacharacters, ie: a node for ;, a node for |,
etc. XSS also has similar concerns and the potential for variants is
far worse if CWE opens the floodgates... how about a node for each
example in RSnake's XSS Cheat Sheet? Nodes like "Script in IMG Tags"
already worry me. :(
I really think attacker input is too dynamic to really classify in
this way. Even with path traversals there are a lot of permutations
that are valid syntax and many that exploit shoddy input validation
routines. It would be hard to ensure that the child nodes provided
complete coverage of the variants. While applications should be
liberal in what they accept, I don't think the CWE should be. ;)
Pen-testers and application developers would probably be just as well
served by having some common examples in the Absolute/Relative Path Traversal
parent nodes via references and context nodes.
It also depends on how you frame the weakness. Is the failure to
filter '../' a different weakness than failing to filter '....//'?
It may be, depending on the implementation.
However, many implementations may be open to all of the variants due
to a complete lack of input validation of user-supplied paths/files --
and I'd personally argue against classifying that as X number of
weaknesses depending on the number of variants in the CWE dictionary.
I see it as one fundamental problem that could potentially be
addressed without specifically filtering every variant.
--
Dave McKinney
Symantec
keyID: E461AE4E
key fingerprint = F1FC 9073 09FA F0C7 500D D7EB E985 FAF3 E461 AE4E
> > As a more general comment--have you given any thought to collapsing some
> > of these together? There seem to be an awful lot of nuanced
> > distinctions. For example, if you were to introduce the term "separator
> > character" which could be equal to '\' or '/' you could quickly
> > eliminate a number of leafs in this section.
>
> We've done a little bit of thinking on this. The path traversal nodes are
> one part of the tree that seems excessively deep.
>
> Note that the current path traversal leaves, such as "..." and "....//",
> are all attack-focused. They concentrate on specific manipulations that
> are nonetheless a little different from each other.
Supporting the attack-focused variants as individual nodes is where
the problem lies I think. I don't see this very often in other parts of the CWE,
where it is often adequate to generalize the issue and then
split-hairs at a higher level than what is being done with 'Absolute'
and 'Relative' Path Traversal.
These variants are either because the OS/filesystem/shell supports
different permutations of path traversal syntax or possibly because
there have been common instances in the wild where an application's
input validation routines have opened the door for new path traversal
variants (in an honest effort to prevent simpler variants). Couldn't
the common cases be described in the context notes without meriting
their own nodes?
Do the variants represent distinct manifestations of a larger problem
or are they just more ways to skin the same cat? I understand there is
a need for both pen-testers and application developers to be aware of
these variants but to me it seems inconsistent with how other CWE
entries have been generalized. For example, if you look at OS Command
Injection as a somewhat similar problem, it does not have child nodes
that reflect specific metacharacters, ie: a node for ;, a node for |,
etc. XSS also has similar concerns and the potential for variants is
far worse if CWE opens the floodgates... how about a node for each
example in RSnake's XSS Cheat Sheet? Nodes like "Script in IMG Tags"
already worry me. :(
I really think attacker input is too dynamic to really classify in
this way. Even with path traversals there are a lot of permutations
that are valid syntax and many that exploit shoddy input validation
routines. It would be hard to ensure that the child nodes provided
complete coverage of the variants. While applications should be
liberal in what they accept, I don't think the CWE should be. ;)
Pen-testers and application developers would probably be just as well
served by having some common examples in the Absolute/Relative Path Traversal
parent nodes via references and context nodes.
It also depends on how you frame the weakness. Is the failure to
filter '../' a different weakness than failing to filter '....//'?
It may be, depending on the implementation.
However, many implementations may be open to all of the variants due
to a complete lack of input validation of user-supplied paths/files --
and I'd personally argue against classifying that as X number of
weaknesses depending on the number of variants in the CWE dictionary.
I see it as one fundamental problem that could potentially be
addressed without specifically filtering every variant.
--
Dave McKinney
Symantec
keyID: E461AE4E
key fingerprint = F1FC 9073 09FA F0C7 500D D7EB E985 FAF3 E461 AE4E
« Return to Thread: Discussion point: CONSPEC - Context-specific Issues
| Free embeddable forum powered by Nabble | Forum Help |
