[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

2-tiered case Re: Expediency or Correctness WAS: Level ofAbstraction

>Russ wrote:
>> If you want something that's simple, has fewer entries, and is less
>> subject to criticism, I'll shut up.
>
>At the risk of incorrectly speaking for MITRE (Bill
>and Steve and a host of others may disagree with me
>on anything I say!), I think what MITRE wants is to
>help facilitate whatever is best for the community.
>That's not a platitude. It really is the driving
>charter of MITRE.
>
>If the right thing for the community is for there
>to be something that is more complex, has more
>entries (and is more work for us all to produce) and
>is subject to less criticism, then by all means, now
>is the time to speak.

Below is an example of a vulnerability that needs to be described at two
different "levels of abstraction", IMHO.

>=================================
>Candidate: CAN-1999-0216
>Published:
>Final-Decision:
>Interim-Decision:
>Modified:
>Announced: 19990630
>Assigned: 19990607
>Category: SF
>
>Denial of service of inetd on Linux through SYN and RST packets.
>
>VOTE:
RECAST
The location of the vulnerability, whether in the Linux kernel or the
application, is debatable.  Any program making the same (reasonnable)
assumption is vulnerable, i.e., implements the same vulnerability:
"Assumption that TCP-three-way handshake is complete after calling Linux
kernel function accept(), which returns socket after getting SYN.   Result
is process death by SIGPIPE"
Moreover, whether it results in DOS (to third parties) depends on the
process that made the assumption.
Since I can't think of a way to represent this by a single entry, the
present entry should be split, one entry for every application that
implements the vulnerability (really describing threat instances, which is
what other people think about when we talk about vulnerabilities), and one
entry for the Linux kernel that allows the vulnerability to happen.

So, one level of abstraction is the "threat instance" (my choice of words)
-- each application that implements the flaw, and this is the "useful for
sysadmins" level.  The other describes the fundamental miscommunication in
assumptions -- the kernel assumes it's the application's job to make sure
the handshake is finished, whereas the applications think it's the kernel's
job, and this is the vulnerability that will (should) be entered in
research-oriented vulnerability databases.
Pascal
Page Last Updated or Reviewed: May 22, 2007