Matt BishopDepartment of Computer Science
3059 Engineering Unit II
phone: +1 (530) 752-8060
fax: +1 (530) 752-4767
email: bishop@cs.ucdavis.edu
The purpose of the DOVES Vulnerability database is to provide a collection of vulnerabilities described in enough detail so the reader can understand the exact cause of the vulnerability. A characterization like "You can make this web server crash," while valuable in many circles, is useless here because it says nothing about how or why the server crashes. The statement "giving the web server a very long input string when it is asking for a URL causes it to crash" is better, because the reader now knows that some sort of an overflow is occurring. The best type of statement is something like "when the web server requests a URL, giving it a very long string causes the stack to overflow and the web server to crash" is an excellent characterization, because is says exactly how and why the server crashes. The only way to do it better is to get the server code and find the lines where the crash occurs. on classifying vulnerabilities through the use of preconditions.)
This document describes of gathering data to fill out the entry. It's meant as a starting point, not as a cookbook, but with luck it will get you started.
The goal of the DOVES database is to describe the vulnerability in enough detail so that an analyst can determine exactly what the problem is. The database is being used to develop a theory of vulnerability analysis (see Bishop's paper [BISH99]). For example, the statement that there is a "buffer overflow" is nowhere near detailed enough. Is the buffer on the stack, the heap, or in data space? Does the overflow change a variable that causes problems, does it corrupt a storage arena and cause a crash (denial of service), or does it overwrite the return address and allow the attacker to execute arbitrary code? This is the information we need. Unfortunately, the information available is rarely presented in the form that makes this simple, so you have to do a bit of detective work.
First, recognize that you may not get the information at the level we need. That's okay, because over time details come out. So write it up anyway!
Your first step is to read the source from which you got the vulnerability. As an example, let's say you want to write up the vulnerability MS00-046 - Patch Available for "Cache Bypass Vulnerability. You heard about this from the SANS Windows Security Digest, vVolume 3 Number 3 (July 31, 2000), item 1.7. Here's what it says:
1.6. MS00-046 - Patch Available for "Cache Bypass" Vulnerability This bulletin announces yet another vulnerability in Outlook Express (OE) which by extension also affects Outlook. A web page can create an web-browser readable file on the user's system. It should only be possible to create such a file in the cache. However, a bug in the implementation allows the file to be created anywhere on the user's hard drive. Files in the cache execute in the Internet Zone and do not have access to any other content on the user's system. However, files outside the cache execute in the Local Intranet Zone, and have access to other files on the user's system. Thus, if an attacker were to create an web browser readable file on the user's system and the user then opened it, the attacker may be able to gain access to other files on the user's system. This problem is fixed in Outlook Express 5.5, which is available with Internet Explorer 5.01 SP1 and, except for Windows 2000, with Internet Explorer 5.5. To fix this vulnerability, take the steps outlined for bulletin MS00-043 in 1.4 above. For more information see: * Microsoft Security Bulletin MS00-046 http://www.microsoft.com/technet/security/bulletin/MS00-046.asp * Frequently Asked Questions: Microsoft Security Bulletin MS00-046 http://www.microsoft.com/technet/security/bulletin/fq00-046.asp * Microsoft Knowledge Base (KB) article Q247638 was not available at the time of this writing http://www.microsoft.com/technet/support/kb.asp?ID=247638This item gives us several leads. First, it cites Microsoft bulletins and other reports. Secondly, it gives a high-level description of the problem. So, let's begin here.
First, get the template from the DOVES home page (see example). Next, go to the title section. This vulnerability is known as the "Cache Bypass" vulnerability for Outlook, so that becomes our title (see example). The first paragraph provides part of the description we need:
A web page can create an web-browser readable file on the user's system. It should only be possible to create such a file in the cache. However, a bug in the implementation allows the file to be created anywhere on the user's hard drive. Files in the cache execute in the Internet Zone and do not have access to any other content on the user's system. However, files outside the cache execute in the Local Intranet Zone, and have access to other files on the user's system.The gist of this description is that if a web page on someone's system creates a page on that same system, it can be created either in the browser's cache or on disk. At this point, a subtlety in Microsoft Windows policy comes into play. When the file is created, if it is created in the cache, it is in the Internet security zone ("Internet Zone") and is constrained by those policy settings. But if it is created on disk, the disk file falls into the intranet security zone ("Local Intranet Zone") and is constrained by those policy settings; and the local zone settings are usually far more permissive than the Internet Zone settings. In particular, the Internet Zone by default prevents anything executing in it from accessing local system files except for those in the cache. The Local Intranet Zone does not restrict this. So this is our first pass at the long description (see example). We will change this if needed when we get to the Microsoft descriptions.
Next, look at the section on where the vulnerability is fixed. This also tells you that earlier versions are probably vulnerable. We'll enter this information into the comp and os sections, and correct and update it if needed. (See example).
The fix points us back to MS00-043, which is described in an earlier vulnerability. Going back there, we see a step-by-step description of how to work around the problem, so we add that (see example). Notice the URL of the patch is included.
Now go to the veffect tag. The description from the SANS write-up says:
Thus, if an attacker were to create an web browser readable file on the user's system and the user then opened it, the attacker may be able to gain access to other files on the user's system.This tells us the effect is to access other files on the system with the privileges of the user who opened them -- a classic Trojan horse. This means the aswho attribute should have the value "user" and the cando attribute should have the value "read". Point out this is a Trojan horse in the description of the effects (see example).
Now we move on to the bulletins, of which the SANS digest names 3:
* Microsoft Security Bulletin MS00-046 http://www.microsoft.com/technet/security/bulletin/MS00-046.asp * Frequently Asked Questions: Microsoft Security Bulletin MS00-046 http://www.microsoft.com/technet/security/bulletin/fq00-046.asp * Microsoft Knowledge Base (KB) article Q247638 was not available at the time of this writing http://www.microsoft.com/technet/support/kb.asp?ID=247638Go to the relinfo section, and put the Microsoft Knowledge Base article before the adv tag. Put the security bulletin in the adv area. For the moment, don't put the FAQ anywhere (see example). Remember, make these URLs so we can get to them.
Now we have milked the SANS article dry. Go to the Microsoft security bulletin. It adds information for our description:
By design, an HTML mail that creates a file on the recipient's computer should only be able to create it in the so-called cache. Files in the cache, when opened, do so in the Internet Zone. However, this vulnerability would allow an HTML mail to bypass the cache mechanism and create a file in a known location on the recipient's disk. If an HTML mail created an HTML file outside the cache, it would run in the Local Computer Zone when opened. This could allow it to open a file on the user's computer and send it a malicious user's web site. The vulnerability also could be used as a way of placing an executable file on the user's machine, which the malicious user would then seek to launch via some other means. The vulnerability would not enable the malicious user to add, change or delete files on the user's computer. Only files that can be opened in a browser window, such as .txt, .jpg or .htm files, could be read via this vulnerability, and the malicious user would need to know or guess the full path and file name of every file he wished to read.We can now sharpen our description. By "web page," the SANS advisory specifically meant HTML, and a mail HTML message at that; this is obvious in retrospect, as Outlook and Outlook Express are mail handlers. Secondly, some of the terms are slightly different. The term "Local Intranet Zone" is more descriptive, because the mail may reside on a file server, so we'll stick with it and put the Microsoft term after, in parentheses. Third, we slightly misread the SANS description as allowing only reading files. In fact, the HTML page could create an executable, so the attacker could also trick the user into executing the file deposited there. So let's clean up the description (see example).
The advisory lists affected software versions:
Microsoft Outlook Express 4.0 Microsoft Outlook Express 4.01 Microsoft Outlook Express 5.0 Microsoft Outlook Express 5.01 Microsoft Outlook 98 Microsoft Outlook 2000so we use those (see example).
Now we look over the fixes described in the advisory. They match the ones outlined in the SANS digest, so we're okay there.
Next, go to the Knowledge Base article. The SANS digest says that the KB article isn't available yet, but we find it's there. So we add the title to the bulletin pointer in the relinfo section.
ccLooking over the knowledge base article, we see it names three components involved:
Ietcomm.dll Msoe.dll Msoert2.dllThese go into the components area (see example).
Now we go to the FAQ named in the bulletin (and in the SANS digest). Often, if you don't understand a vulnerability, going to the FAQ first will give you enough information to figure it out. In particular, this FAQ points out that the "cache" is a set of folders and not in-core memory or something other than the disk (this confuses people who haven't wrorked with this aspect of Windows before). Second, it describes the mechanisms that are used when the system works correctly. However, it does not delimit the methods used to create a file outside the cache, and that's really what we need to know here.
Now we need to fill out the rest of the entry. For detection, go to the patch described in the advisory, and look there for what systems need to be patched. You'd expect this was in the comp area, but sometimes those programs invoke other programs or DLLs that need to be patched, so the detection is quite different.
1.Click Help in the Outlook Express File Menu and then click About Outlook Express. 2.Apply this update if Version: is displayed as 4.72.3612.1700 for Outlook Express 4.01 SP2, or 5.00.2919.6600 for Outlook Express 5.01 (if you are running Windows 2000, the Outlook Express 5.01 version number will display as 5.00.2919.6700).We now know how to detect the vulnerability. If any of those versions of Outlook or Outlook Express is running, you are vulnerable. So, go to the vdetect area and add this information (see example). As there is only one technique, we omit the tech tags. We also added a short description for this example, and selected as keywords email, Trojan horse, and web page. We deleted the vother section filler too.
Now for the other web sites and advisories. First go to the CVE web page and search for the vulnerability. We used the search term "outlook Express" and found several. This is a recent one, so go to the bottom of the list (they are listed in reverse chronological order, roughly) and there it is: CAN-2000-0621, and they even say it's "aka the Cache Bypass Vulnerability." So, now we add it to the CVE entry in the cat section. Looking at the PA list, it is probably an improper choice of an initial protection domain, and an improper choice of operand or operation, so we put those two in. For RISOS, again, it looks like a case of inadequate identification/authentication/authorization, so we add that, too (see example).
Now go to the bottom of the CVE description. You will see a field for other references; here, it contains:
MS:MS00-046 URL:http://www.microsoft.com/technet/security/bulletin/MS00-046.asp CERT:CA-2000-14 URL:http://www.cert.org/advisories/CA-2000-14.html BID:1501 URL:http://www.securityfocus.com/bid/1501These are the other references we need. We have the first two (Microsoft bulletins). The next two are a CERT advisory, and we need to include it. It also says the Microsoft reported this problem, so that suggests that Microsoft may be the reporter. The last two refer to Bugtraq, and so we go to the given URL.
Bugtraq is another good place to go if you have trouble understanding the vulnerability. The "Discussion" tab tends to be quite descriptive. Look at the contents; it seems the description we did matches. Look at the "Exploits" tab. There is none here, but if there were, you should get it, put it into a separate file, and in the attack part of the exploit field, say what the file is. Then look at the "Solutions" tab and see if it tells us anything more. Finally, go to the "Credit" tab. Like the CERT advisory, that says Microsoft's security bulletin is the first report. So we use that for the credit (see example).
Finally, we add revision information. We're done! (See example).
You should always look at the following for vulnerability information. You may not find anything, but if you do please put it into the relinfo section.
Matt Bishop
Department of Computer Science
3059 Engineering Unit II
phone: +1 (530) 752-8060
fax: +1 (530) 752-4767
email: bishop@cs.ucdavis.edu