Due Date: May 9, 2000
Points: 200
<!-- This is an SGML comment.
The next line identifies the dtd and document type and must be
included in every vulnnerability description. -->
<!DOCTYPE vdbentry SYSTEM "vulner.dtd">
<!-- The next line begins the document type and identifies it as
a vulnerability database entry. The "refer" attribute is the
number of the vulnerability in the database; the DOVES
registry (for now, at UC Davis) will assign it. -->
<vdbentry refer="V-nnnnn">
<!-- the title of the vulnerability -->
<title>
</title>
<!-- the descriptive components of the vulnerability -->
<desc>
<!-- a short description; one or two sentences -->
<short>
</short>
<!-- a long description; what causes the vulnerability, in
detail (if you have code, put it here!) -->
<long>
</long>
<!-- components involved in causing the vulnerability; these
can be program names, files, and anything necessary for
the vulnerability to occur; if there is a version
associated with any component, give it (and label it
verified, trusted, or unverified) -->
<comp>
</comp>
<!-- on what operating system or windowing system has it been
seen? the os need NOT be involved in the vulnerability!
again, if there is a version associated with the os
involved, give it (and label it verified if you yourself
have seen it or found it; trusted if you've not seen it
but someone or some source you trust has announced it --
be sure you identify the source in the history section;
or unverified if this is a rumor or something you've heard
but are not too confident of -->
<os>
</os>
<!-- the effect of the vulnerability being exploited; this is
to be a description of what happens; the access field
gives a short, one-word desription of the effect (choose
one of the words below) -->
<veffect access="root|user|read|write|execute|deny">
</veffect>
<!-- how do you detect this vulnerability? list these as
multiple techniques; an implicit one is to use the attack.
don't list that one here; list techniques to find the
vulnerability that don't involve attacking -->
<vdetect>
<!-- you can have numerous techniques to locate a
vulnerability -->
<tech>
<!-- the technique may have 0 or more steps; put
these around each step -->
<step>
</step>
</tech>
</vdetect>
<!-- how do you fix this vulnerability? list these as multiple
techniques -->
<vfix>
<!-- you can have numerous techniques to fix a
vulnerability -->
<tech>
<!-- the technique may have 0 or more steps; put
these around each step -->
<step>
</step>
</tech>
</vfix>
<!-- put anything else into this category; if you want to add
fields, put them in here for now and they can be moved out
later -->
<vother>
</vother>
</desc>
<!-- list meaningful keywords; check the keyword catalogue
first to see if any there apply (the registry will add
new ones as you list them) -->
<keyword>
</keyword>
<!-- this section contains cataloguing information for other
catalogues -->
<cat>
<!-- if you have a classification scheme, make up an
SGML tag for it; you will maintain all
classifications for it. Current tags follow.
pa = program analysis project category -->
<pa>
</pa>
<!-- risos = research into secure operating systems
category -->
<risos>
</risos>
<!-- dcs = decomposition classification scheme category -->
<dcs>
</dcs>
<!-- mitre = CVE classification; refer is number, field
is CVE cluster -->
<mitre refer="#####" field="#####">
</mitre>
</cat>
<!-- this section contains pointers to attacks; they refer
to the exploits section of the database -->
<exploit>
<!-- this is where you put the pointer to the attack;
you can list several attacks, one per field -->
<attack>
</attack>
</exploit>
<!-- this section contains related information such as
pointers to advisories, other vulnerabilities, and
papers, and so forth; feel free to explain the
relevance of anything you put in here -->
<relinfo>
<!-- advisories and other references; put URLs if
you have them (we will try to fill them in if
you don't want to) -->
<adv>
</adv>
<!-- put DOVES references in here; again, we will
try to fill out cross-references of other
vulnerabilities, attacks, and signatures unless
you don't want to -->
<ovn>
</ovn>
</relinfo>
<!-- this section contains bibliographic information for
the vulnerability; please be as precise as you can,
since we want to give credit where credit is due -->
<history>
<!-- this says who reported the problem,and where;
you can have multiple of these sections -->
<report>
<!-- who; give email address if you've got it (or other
contact info, such as a web page) -->
<reporter>
</reporter>
<!-- where was it reported; please be as precise
as possible (message IDs are nice if the
messages are publicly available) -->
<where>
</where>
<!-- when was it posted/announced/etc. -->
<when>
</when>
</report>
</history>
<!-- this section contains bibliographic information for
the ENTRY; say what you changed in the entry (or
say that you created the entry) and when; please put
enough information in there so we can contact you!
We will pull that out, add you to our database of
contributors, and put your name or ID into the "who"
field when we distribute it, again unless you tell
us otherwise -->
<revision>
<!-- here's where you put your info; you can have
multiple of these, one per alteration (or user) -->
<changes date="" who = "">
</changes>
</revision>
<!-- ALL DONE! (PHEW!) -->
</vdbentry>
Send email to
[email protected].
Department of Computer Science
University of California at Davis
Davis, CA 95616-8562