Prologue
This identifies the document as a vulnerability entry. It consists of two lines. The first says what the DTD is (in SGML parlance, a DTD describes the structure of the document):
<!DOCTYPE vdbentry SYSTEM "vulner.dtd">This says the document begins with a vdbentry tag, and ends with one. The DTD is not a standard one, and has the name "vulner.dtd". The programs that parse SGML are responsible for knowing where that file is (or you can tell them with command-line options). The next line is:
<vdbentry refer="V=nnnnn">where nnnnn is the DOVES number of the vulnerability. If you haven't been told what this number is, just leave it as "nnnnn" and we'll fix it up.
At the very end of the document, you need to close this tag. So that line must be
</vdbentry>
Title
Create a short but descriptive title, and put the tag title around it, like this:
<title>WWW Browser Buffer OVerflow on URL Input</title>This will be used to generate an index for the main web page.
Description
The description section describes the vulnerability. It is surrounded by the desc tag and consists of several parts.
Short Description
This section (surrounded by the short tag) gives a very terse description of the vulnerability. Please make it clear enough so a reader can figure out what the vulnerability is. The last of the three sentences in the introduction's example is a good short description. Here's another:
<short> The ... package does not check its input adequately, allowing users to insert metacharacters to force remote execution of a command. </short>This immediately allows the reader to conclude that one can force unauthorized commands to be executed remotely, and that it's because the input is not checked adqeuately.
Long Description
This section (surrounded by the long tag) should give as detailed a description of the vulnerability as possible. Include code, a detailed description of why the vulnerability works, and anything else that you think will be helpful in understanding the problem. If it would be helpful, you can include information about an exploit, but do so only if it helps explain the vulnerability. There's a separate section for exploits.Use the <para> tag to separate paragraphs.
If you want to include code, there are two tags you'll find helpful. The tag code surrounds code that fits on a single line. The tag codeblock surrounds a multi-line segment of code and tells the formatters to print the code as shown. See the section on Inline Constructs, below.
Components
This section (surrounded by the comp tag) names the affected components. Please be as precise as you can, and if you know some versions are not affected, name them and say "not vulnerable". If the components are vulnerable only on some versions of the OS, name those versions. Here are some examples:<comp> bind 8.1.1 and earlier, bind 4.9.6 and earlier </comp>Here, a couple of different versions are affected.
<comp> kernel </comp>It's a kernel bug. If you can name the specific kernel component (process manager, file system, etc.), that would be great. Here, we couldn't.
<comp> Microsoft Outlook Express 4.0, 4.01, 5.0, 5.01; Microsoft Outlook 97, 98, and 2000 when a POP3 or IMAP4 server is used </comp>Several versions of Microsoft Outlook have this problem, and some versions have to be configured to run POP3 or IMAP4 to have the vulnerability.
Operating System
This section (surrounded by the os tag) names the system on which the vulnerability occurs. If the problem is independent of operating system (that is, the program runs on all systems you know of and has the bug on them all), leave this blank. Otherwise, list the systems on which the buggy compoonents run.Effect
This section (surrounded by the veffect tag) describes what an attacker can do. Please use the worst-case scenario that comes from only the listed vulnerability. For example: "The attacker can run code with the privileges of Outlook" is good, because it tells the reader that whatever privileges Outlook runs with, those are the privileges that the attack code will run with. For query purposes, this tag has two attributes. The first attribute is aswho:| aswho value | meaning |
|---|---|
| root | unrestricted access to the system |
| user | runs as the user running the attacked component; for example, if the program is running as the user "andy", the attack code will run with the user "andy"'s privileges |
| anyuser | can run as any user on the system except the omnipotent user ("root" for UNIX-ers, "Administrator" for Windows folks) |
| cando value | meaning |
|---|---|
| read | can read objects |
| alter | can alter objects |
| run | can execute objects |
| readalter | can read and write objects |
| readrun | can read and execute objects |
| alterrun | can write and execute objects |
| block | block access to objects (use this if the attacker does not use the object) |
| hog | consume the object so no one else can use it |
| any | all of the above |
<veffect aswho="user" cando="any"> Intruders can execute arbitrary commands with the privileges of the web server process. </veffect>Here, the web server process is probably at the root or Administrator privilege level, but if not the attacker can only run with the privileges or the server. Hence the "user" value for the attribute aswho.
<veffect aswho="root" cando="run"> The attacker can execute code with the privileges of the BIND daemon </veffect>Here, the BIND daemon must run as root. So the aswho attribute can be set to "root".
<veffect aswho="user" cando="hog"> The attacker can open more file descriptors than the system specifications allow. </veffect>The "hog" value for cando arises because there is a per-system and per-user limit on the number of open file descriptors. In this particular vulnerability, the per-process limit is not enforced adequately, so one process could evade the per-process limit and acquire the maximum number of file descriptors allowed for the user or computer. Hence it's using those descriptors and denying others access to them. This gives the "hog" attribute.
Detection
This section is important because sometimes it gives insight into the nature of the problem. It is split up into several subsections, each called a "technique" (and surrounded by tag tech). Each "technique" is composed of multiple "steps" (and surrounded by tag step). Here are some examples:
<vdetect> <tech> Check the date of the DLL <file>psbase.dll</file>. If that is earlier than July 25, 2000, you are vulnerable. If you have installed Windows 2000 Service Pack 1, you are not vulnerable. </tech> </vdetect>This is a technique with one step, so we omit the step tag. This one is pretty much self-explanatory.
<vdetect> <tech> BIND version 8: Look at the options block in the configuration file for BIND. If the line <codeblock> fake-iquery yes; </codeblock> is there, you are vulnerable. </tech> <tech> BIND version 4.9: <step> Look at the options block in the configuration file for BIND. If the line <codeblock> fake-iquery yes; </codeblock> is there, you are vulnerable. </step> <step> Check the source header fileThis one is more complicated. The technique used depends on which version of BIND you are running. If it's version 8, you have one step. If it's version 4.9, you have two steps, and so you need the tag.conf/options.h . If the line <codeblock> #defining INVQ </codeblock> is there, you are vulnerable. </step> </tech> </vdetect>
If there is only one technique, and one step, omit the tech and step tags. Otherwise, include the tech tag. You can omit the step tag unless there are two steps to the technique.
Repair
Like the previous subsection, this section is important because sometimes it gives insight into the nature of the problem. It too is split up into several subsections, each called a "technique" (and surrounded by tag tech). Each "technique" is composed of multiple "steps" (and surrounded by tag step). Here are some examples:<vfix> <tech> Upgrade to the latest version of BIND or apply the relevant patch. </tech> <tech> Disable inverse queries. <step> Edit the config file, either deleting the following line of changing the "yes" to "no": <codeblock> fake-iquery yes; </codeblock> </step> <step> If you are running BIND 4.9, also edit the source header fileThese are the instructions to fix the vulnerability. They are often immediate from the detection step, but sometimes they are substantially different. Even if they are as simple as "install the patch," that tells usconf/options.h and delete or comment out the line <codeblock> #defining INVQ </codeblock> </step> </tech> </vfix>
Other Descriptive Information
This section is a catch-all for any information that you think is useful or interesting to the reader but didn't fit into any of the other subsections. It is surrounded by the vother tag.
Keywords
List keywords here. For now, just use your imagination. Try to be as pithy and yet as descriptive as possible. Over time, we will build a list of keywords for you to pick from. This section is surrounded by the keyword tag.
Catalogue Information
This section is the heart of the database entry. It classifies the vulnerability under several schemes. It is surrounded by the cat tag.
Program Analysis
The classifications for the Program Analysis project are from Peter Neumann's paper [NEUM78]. The following table summarizes them:
| entity | Classification |
|---|---|
| &init; | Improper choice of initial protection domain (domain) |
| &detail; | Improper isolation of implementation detail (exposed representations) |
| &change; | Improper change (consistency of data over time) |
| &naming; | Improper naming (naming) |
| &deallococation; | Improper deallocation or deletion (residuals) |
| &validation; | Improper validation (validation of operands, queue management dependencies) |
| &indivisible; | improper indivisibility (interrupted atomic operations) |
| &sequence; | improper sequencing (serialization) |
| &choice; | Improper choice of operand or operation (critical operator selection errors) |
Place the entity or entities corresponding to the vulnerability in the text, and surround them with the pa tag.
RISOS
The classifications for the RISOS project are from the RISOS paper [ABBO76]. The following table summarizes them:
| entity | Classification |
|---|---|
| &incomplete; | Incomplete parameter validation |
| &inconsistent; | Inconsistent parameter validation |
| &share; | Implicit sharing of privileged/confidential data |
| &async; | Asynchronous validation/inadequate serialization |
| &iaa; | Inadequate identification/authentication/authorization |
| &nolimit; | Violable prohibition/limit |
| &logicerror; | Exploitable logic error |
Place the entity or entities corresponding to the vulnerability in the text, and surround them with the risos tag.
CVE
The CVE number provides a commoin framework for discussing specific vulnerabilities. The numbers are available from MITRE. Multiple entries may apply to a single DOVES entry, because the CVE uses a slightly different definition of vulnerability than we do.
For each CVE entry, surround the descriptive text in the CVE entry with the cvenum tag. That tag takes one attribute, refer, which is the CVE number or candidate CVE number. Then these are surrounded by the cve tag. Some examples are:
<cve> <cvenum refer="CVE-1999-0147"> The aglimpse CGI program of the Glimpse package allows remote execution of arbitrary commands </cvenum> </cve>Here, there is one CVE entry for the vulnerability.
<cve> <cvenum refer="CAN-2000-0485"> Microsoft SQL Server allows local users to obtain database passwords via the Data Transformation Service (DTS) package Properties dialog, aka the "DTS Password" vulnerability. </cvenum> </cve>Here is a candidate CVE entry. This has not yet been accepted by the editorial board, so it uses the "CAN" designation.
Exploit
This section is surrounded by the keyword tag and contains a pointer to exploits. It contains only the attack element.
Attack
For now, copy the exploits into a separate file and put the file names here. Those will go into a separate database currently under design. If you have signatures of attack, we welcome those too. Again, put them into a separate file or files and name the files here. Surround the text by the attack tag, even if it is a signature ...
Related Information
This section contains related information and it, and the next two subsections, are surrounded by the >relinfo tag. The first part contains any non-advisories; for example, Microsoft Knowledge Base article references go here. When you create an item, please include the URL so others can get to it. Do this by surrounding the title with the href tag, like this:Microsoft Knowledge Base article <href url="http://www.microsoft.com/technet/support/kb.asp?ID=260219"> Q260219, High Encryption Pack Does Not Protect Windows 2000 Private Keys</href>As another example, CERT had a couple of good papers on problems with CGI scripts and metacharacters. Here is the prologue of the relinfo section:
CERT Advisory <href url="http://www.cert.org/advisories/CA-97.25.CGI_metachar.html"> CA-97.25.CGI_metachar, Sanitizing User-Supplied Data in CGI Scripts</href> has general advice on sanitizing user input for CGI scripts that is relevant. The <href url="http://glimpse.cs.arizona.edu/webglimpse">Project FUSE web site</href> has a page about <href url="http://webglimpse.org/security.html">GlimpseHTTP</href> security.Note no tags surround this part.
Advisories
The tag adv surrounds this information. Put in here any relevant advisories you come across. The format of each should be the URL in an href tag surrounding the title. Also, the advisories should be in an unordered list, just like in HTML. Some examples:<ul> <li>ISS X-Force database entryThe X-Force and CERT advisories should be there if they exist. The other critical one is the Security Focus database; for example,http-cgi-glimpse</href> <li>CERT Vendor-initiated bulletin VB-97.13, Vulnerability in GlimpseHTTP and WebGlimpse CGI scripts</href> from Project FUSE </ul>
<li>ISS X-Force database entry <href url="http://xforce.iss.net/static/895.php">bind-bo</href>; CERT Advisory <href url="http://www.cert.org/summaries/CS-98.04.html">CA-98.05, Multiple Vulnerabilities in BIND: 1. Inverse Query Buffer Overrun in BIND 4.9 and BIND 8 Releases</href>; <li>CIAC Advisory <href url="http://ciac.llnl.gov/ciac/bulletins/i-044a.shtml">I-044A: BIND Vulnerabilities</href>; <li>Security Focus database entry <href url="http://www.securityfocus.com/bid/134">134</href>; <li>SGI Advisory <href url="ftp://sgigate.sgi.com/security/19980603-02-PX">19980603-02-PX, IRIX BIND DNS Vulnerabilities</href>; </ul>Note that the ul and li tags work just like in HTML.
Other Vulnerabilities
The tag ovn surrounds this information. List here other DOVES vulnerabilities that are related. For example:
<ul> <li><vref url="v-00100.sgml">AGlimpse meta-characters</vref> <li><vref url="v-00101.sgml">AnyForm meta-characters</vref> </ul>The vulnerability titles are surrounded by the vref tag, and its attribute is the vulnerability number followed by the ".sgml" extension (note the lower-case "V"). The processing scripts automatically fix this up to refer to the correct page number or Web page.
History
The tag history surrounds this information. This lists who first reported the problem. In some cases, different people or groups may report different aspects of the problem. Also, multiple people may independently discover the same problem. Hence this section consists of one or more report sections.
Report
This section is surrounded by a report tag. It consists of four parts:Reporter
This section, surrounded by the reporter tag, names the individual or organization that reported the problem. If available, give an email address (using the email tag) or a URL (using the href tag). For example:
<reporter> <email url="mailto:drazvan@kappa.ro">Razvan Dragomirescu </reporter>Here's an example using an email address. It's just like a web page reference but with an email tag instead of an href tag. If there is no associated email address, just supply the name:
<reporter> Zuo Lei </reporter>
Where
This section, surrounded by the where tag, says where the problem was reported. Again, give the URL if appropriate; but a single phrase may also work, especially if the URL of the report is already in the advisory section. For example,
<where> ISBASE Advisory </where>The URL of this advisory is given earlier in the entry.
<where> Microsoft security bulletin </where>This came from an entry of a vulnerability that Microsoft reported in a security bulletin that, again, is referenced earlier.
When
This section, surrounded by the when tag, says when the problem was reported. For example:
<when> July 20, 2000 </when>
What
This section, surrounded by the what tag, says exactly what the person reported. It could be as simple as:
<what> reported the problem </what>or, in the case of multiple reports,
<what> independently discovered the problem and reported it to Microsoft </what>
Revisions
This section, surrounded by the revision tag, lists the changes made to the entry in general terms. Its single attribute, revno, is the current revision number. Its body consists of a sequence of change entries.
Changes
This describes the changes one person made. It is surrounded by the changes tag, which takes three attributes. The attribute m is an integer representing the month (January is 0, December is 12); the attribute d is an integer representing the day of the month; and the attribute y is an integer representing the year (please give all four digits; write "1999" for 1999 and "2000" for 2000). The last attribute, who, is who made the change. Here are some examples:
<changes m=8 d=1 y=2000 who="Matt Bishop"> Initial entry </changes>If you create the entry, the body of this field is "Initial entry".
<changes m=5 d=23 y=2000 who="John Doe"> Initial entry </changes> <changes m=8 d=1 y=2000 who="Matt Bishop"> Made the long description more precise because we got the actual code </changes>
Inline Constructs
There are several constructs that can be used throughout the text of the entry. Some have been presented, but are reviewed here.
- aref
- This surrounds an entity describing an attack, and its attribute url, is set to the attack entry in DOVES. Be sure to put the SGML form of the attack in; the postprocessors will change that to the right web page.
- code
- The surrounded text is formatted as though it were program code. This does not prevent filling and reformatting, so use this only for very short code fragments. Also, if the code contains a less than (<) sign or an ampersand (&), you must write it as < and &, respectively. (These signs are meaningful to the SGML parser and will be mapped to SGML elements, or cause error messages).
- codeblock
- This is like code, except that the formatting elements such as no-fill and line breaks are preserved. It is most suitable for multi-line code fragments. As with code, you have to write & and < for ampersand and less than, respectively.
- This surrounds an entity to which mail can be sent, and its attribute url, is set to the email address.
- file
- This surrounds a file, directory, or other file system object name.
- func
- This surrounds the name of a function. It may be a system call, a library function, or a function defined in the program under discussion. It has the optional attribute mansec, which names the manual section or page describing the system call or library function (if that is what the function is).
- group
- This surrounds the name of a group.
- href
- This surrounds an entity describing a web page, and its attribute url, is set to the web page URL.
- li
- This surrounds an element of an ordered or unordered list, just like for HTML.
- ol
- This surrounds an ordered list, just like for HTML.
- para
- This is used to separate paragraphs.
- prog
- This surrounds the name of a program or process. It has the optional attribute mansec, which names the manual section or page describing the program or process.
- regkey
- This surrounds the name of a (usually Windows) registry key
It has the attribute regkey,
which should be the name of the key.
The body of this should say what the key does. For
example, the ADCLaunch key could be referred to as this:
<regkey key="HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\ADCLaunch">ADCLaunch</regkey>
- role
- This surrounds the name of a role.
- sref
- This surrounds an entity describing a signature, and its attribute url, is set to the signature entry in DOVES. Be sure to put the SGML form of the attack in; the postprocessors will change that to the right web page.
- system
- This surrounds the name of a subsystem (a set of programs or processes to carry out some task; this is not for the operating system!) It has the optional attribute mansec, which names the manual section or page describing the system
- ul
- This surrounds an unordered list, just like for HTML.
- user
- This surrounds the name of a user.
- var
- This surrounds the name of a variable (program or environment).
- vref
- This surrounds an entity describing a vulnerability, and its attribute url, is set to the vulnerability entry in DOVES. Be sure to put the SGML form of the attack in; the postprocessors will change that to the right web page.
Checking Your Entry
To see if your entry is structured correctly, use the program nsgmls. First, get a copy of the vulner.dtd file from the web page. Put it in the same directory as your test entry. Be sure your test entry is in a file with the name ending in sgmls. (Call this file "test.sgml".) Then run:
nsgmls test.sgmlIf the last line is a "C", you're fine. If not, error messages will appear on the standard error.
References
- [ABBO76]
- R. P. Abbott, J. S. Chin, J. E. Donnelly, W. L. Konigsford, S. Tokubo, and D. A. Webb, "Security Analysis and Enhancements of Computer Operating Systems," Technical Report NBSIR 76-1041, ICET, National Bureau of Standards, Washington DC 20234 (Apr. 1976).
- [BISH99]
- Matt Bishop, "Vulnerabilities Analysis," Proceedings of the Recent Advances in Intrusion Detection (Sep. 1999)
- [NEUM78]
- Peter G. Neumann, "Computer Security Evaluation," 1978 National Computer Conference, AFIPS Conference Proceedings 47 pp. 1087-1095 (1978).
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
Last modified on August 4, 2000