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

Re: Level of Abstraction Issue: Similar Applications, "Same" Vulnerability

Steve,

	I continue to believe that the same codebase is the correct
LOA.

	In addition, I want to correct a misconception that you have
about the way a scanner would detect this problem.  "Since the attack
is the same, the test is the same."

	This might be correct if the attack were precisely the same,
eg, teardrop; then the same test might be used.  However, lets look at
how we might actually test for this vulnerability.  First, we might
send some exploit mail.  This would work ok, except we have no idea
when you'll next read your mail, so how long should we wait for a
result?  Next, we might try to access the registry and read the
HKLM\software\msft\exchange\version key to see whats there.  Note that
this is qualitatively different in a number of ways; it requires
credentials on the tested machine, it infers rather than exploits the
vulnerability, etc.  That may well work if we have credentials.  If we
don't, we may try to get anonymous access to \\host\\C$, and checksum
the Outlook binary.  We might even try to find access to the mail
server, watch for mail sent by the user, and read a header line to 
see that the mail client is out of date.

	Next, as a sysadmin, I'd be suprised to see the same
vulnerability in a MS client and a Sun client program, and my fix
activities and scheduling would be different.

	So, given that I don't think scanners operate at this LOA, and 
further, that a sysadmin doesn't want this LOA, I urge you to
reconsider.

Adam


On Mon, Jun 28, 1999 at 04:43:16PM -0400, Steven M. Christey wrote:

| Cons:
|   - lower level than necessary for IDSes; since the attack is the
|     same, the signature is the same (IDS people, please don't slam me
|     for overgeneralizing ;-)
|   - lower level than necessary for scanners; since the attack is the
|     same, the test is the same
|   - increases the raw number of vulnerabilities that a CVE "end
|     user" (sysadmin) must consider fixing/verifying (whether reported
|     by IDSes or network scanners, or as generated by a CVE-savvy
|     vulnerability database)
|   - in some cases, it may not be easy to know if 2 applications
|     have the same "code base" or not, without interacting more
|     closely with the app. vendor.  Consider a Sendmail bug that
|     affects multiple OSes; did each OS vendor make the same mistake
|     when tweaking the application for their OS, or was the bug from
|     Allman's original code?  We can only make this distinction by
|     analyzing the source code and/or depending on vendors to provide
|     us with such information, which can introduce (a) delay while
|     waiting for vendor response (CERT model), or (b) error if we
|     make guesses without the vendor's response, which might require
|     some "renumbering" later on (ie splits or merges)
| 
| 
| I believe that the Same Attack approach has more practical, everyday
| usage than Spaf's Same Codebase perspective, since (a) it's at the
| level that IDSes and scanners would operate at; and (b) it's at the
| level that (in my experience) sysadmins like to see it at, especially
| as they pore through the voluminous results of security tools.  I
| believe that as long as we make sure that the description identifies
| all affected applications, then the current CVE content decision
| remains the most appropriate for the community at large, especially
| when considering the "end users."
Page Last Updated or Reviewed: May 22, 2007