RE: Survey: Use of Same Attack/Same Codebase content decision in VDB's

[Russ <Russ.Cooper@rc.on.ca>]

Ok, I'm confused. Paul Proctor said that 1) sechole, 2) getadmin, 3)
unauthorized addition of a user to the administrator's group are all the
"same hole". The "hole", presumably, is known only to Paul??

"Sechole" exploits a vulnerability that existed in the way NTOpenProcess
validated its success or failure parameter, thereby allowing
DebugActiveProcess to be fooled into believing it succeeded in opening
the process it was going to debug (thereby by-passing authentication
failure, not altering authentication).

"GetAdmin" exploits a vulnerability in NTAddAtom that allowed the
exploit to turn off the check for debug privileges in NTOpenProcess and
NTOpenThread (thereby removing authentication verification completely).

"unauthorized addition of a user to the administrator's group" was done
recently by the guy who fixes my computers while he was trying to verify
a new hub, he simply walked up to one of my consoles that was logged on
as Administrator and created himself a new user (and made it a member of
the Administrators group). I hadn't authorized him to do so.

I really do fail to see how these are the "same hole". If this is all
the CVE is about then we're going to have very few entries.

Besides, the love of adding a user to Administrators group is simply a
means to an end, typically, gaining access to unauthorized resources is
the real goal.

Matt Bishop's somewhat confusing mention that "The program may not have
changed at all. But the OS, and hence the
effect of the same attack upon the same codebase, may have (has, in the
above example)." got me also. My take on what he said was that given an
attack program foo.exe, against OS Bar v1, a crash may result. foo.exe
against OS Bar v2 might cause "supervisor privilege" instead, due to
changes in OS Bar. While this is true, that represents an attack-centric
scheme. There are two vulnerabilities here, albeit with one attack
program that can exploit them (differently). My hope is that this is
what Matt meant?

What I see as a very large portion of this decision is the level of
detail we will be able to get on the "issue" from the Vendors. Let me
explain;

The recent IIS Buffer Overrun discovered by eEye appeared to affect one
specific vulnerability. Namely, the use of .HTR file types. Mechanism
not installed, Buffer Overrun not present, or so it seemed. In fact, MS
discovered that the exact same codebase had been used for the
implementation of support for both .STM and .IDC file types. Since each
can be supported independently of the other, and each required separate
modifications to binaries to correct, it would stand to reason that they
all would be individual CVE entries representing unique vulnerabilities.

The fact that the same exploit code could overrun 3 different file type
filters shouldn't enter into this. What might alter the 3 x CVE items is
the fact its the same code flaw. As Mike Prosser said earlier, is this 1
vulnerability or 3?

Although I agree with Elias' take that we cannot be omnipotent, and we
don't want the CVE to be full of errors, I ask the question...if we
cannot get sufficient level of detail from vendors...eventually...then
how can we even tell if an attack is using the same method as some
previous attack. If two different attacks use similar, but different
methods to gain the same, or similar results (ala GetAdmin and Sechole),
*should* they really be classified as the same CVE item even though they
may affect vastly different codebases (NT SP3 versus NT SP4)??

If we say yes, then this really boils down to "Similar attack/Similar
Results", or we end up with far more CVE items than I think we want to.

My vote is that we work on the assumption that "Same Attack/Same
Results" should be the starting point for any CVE item, and, assuming
details are forthcoming from a vendor, the CVE item gets revised
according to the details as they unfold. My personal feeling is that we
should concentrate on "Same Attack", and leave "Same Codebase" and "Same
Results" to vulnerability databases to elaborate on (i.e. with wonderful
matrices or something).

On the surface, Sechole and Getadmin would have been put under the same
CVE. As details unfolded, it would have become obvious they represented
different attacks, and therefore, would have been split into multiple
CVE items. Should some similar program come along that either creates
different results, or modifies the way it reaches the same API exploit,
it would be ignored by the CVE as a duplicate. If some Quang(sp?)-like
tool came along and assembled the two into a new result, it too would be
ignored as a duplicate.

I believe this approach will lead to the most unique CVE items, albeit
at the expense of more revisions as/if details emerge.

Sorry for having been away from these discussions for so long.

Cheers,
Russ - NTBugtraq Editor