<!-- 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 = Davis classification scheme category -->
<dcs>
</dcs>
<!-- mitre = CVE classification; refer is number, field
is CVE cluster -->
<mitre refer="#####">
</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>