[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."