Candidate Submission Format (CSF)
Candidate Submission Format (CSF)
Below is a description of the Candidate Submission Format (CSF), along
with some examples. This format will be used for submitting
vulnerability or exposure information for inclusion in CVE. You can
use it to submit your "top 100" list or "six month" list. See my
PLEASE DO NOT SEND ANY BRAND-NEW INFORMATION YET. Restrict your
information to that which was known before November 1, 1999. New
submissions may have slightly different requirements.
This format may change as time goes on.
Submission - a piece of security-related information that someone
sends to a CNA which may then be converted into a candidate. The
*Submission* phase occurs before the *Assignment* phase of a
Submitter - the organization who is providing the submissions.
Legacy Cutoff Date - a date where problems will be considered "legacy"
if they were known to exist before that date. The Legacy Cutoff Date
will be specified when brand-new information is being reliably
submitted by enough sources to assure a high degree of timely coverage
of new security problems. In other words, the Legacy Cutoff Date has
not been specified yet, but it will likely be defined sometime in
November or December 1999.
New Submission - a submission for a problem that is made public after
the Legacy Cutoff Date
Legacy submission - a submission for a problem that was publicly known
before the Legacy Cutoff Date. At this time, all problems are
considered to be Legacy.
All text provided by the submitter for legacy submissions is assumed
to be copywritten, unless explicitly stated otherwise. Therefore:
- Candidates resulting from those submissions will use reworded text
(except cases where duplication is highly likely e.g. "Smurf
denial of service,"), unless the submitter explicitly states that
it is OK to copy the text
- Submission information will not be provided to any entity outside
of MITRE's internal CVE team (but the resulting candidates will be
provided, of course).
<CR> - carriage return
<LINETEXT> - single line of ASCII text followed by a <CR>
<FREETEXT> - multiple lines of ASCII text followed by a <CR>
:LEGACY<CR> - start a legacy submission entry
:END<CR> - end a legacy submission entry
:DESC<CR><FREETEXT> - CVE-like description (1-3 lines)
:REF <LINETEXT> - publicly available reference (URL/ID/etc.)
:INTID <LINETEXT> - submitter's internal ID for the submission
:KEYWORDS <LINETEXT> - comma-separated list of keywords
:SHORT <LINETEXT> - single-line description/short name
:APPNAME <LINETEXT> - Name of affected application/OS
:DETAILS<CR><FREETEXT> - additional details
:EXTENSION <KEYWORD> <LINETEXT> - ad hoc "fields" to provide
You can have multiple :REF's per submission.
Don't worry about how the CNA will parse <FREETEXT> specifiers. It is
highly unlikely that raw descriptive text will have a submission
specifier in it. It will be less labor intensive for the CNA to
handle those rare cases than it will be for you to re-format your
descriptions to conform to any syntactic weirdness for CSF.
Required Specifiers for Legacy submissions
For legacy submissions, you will not be required to do much
"post-processing" or "massaging" of the data that you have, as that
could require a lot of resources to accomplish. However, you are
strongly encouraged to provide as much additional information as
possible to simplify the data integration and reduce the chance of
[:SHORT | :DETAILS | :DESC]+
You must provide a textual description. The specific description
depends on what your database uses. You are not required to use a
CVE-like :DESC unless you have one available. You can use more than
one of :SHORT, :DETAILS, or :DESC.
Strongly Encouraged Specifiers for Legacy submissions
You are STRONGLY ENCOURAGED to provide:
:KEYWORDS and/or :SHORT
A :REF, once it makes it into a candidate, will help other voters, CVE
mappers, etc. to know which specific problem is being presented
:KEYWORDS and/or :SHORT will help to reduce the data integration
effort by providing a small set of relevant terms to use in search.
Other Specifiers for Legacy submissions
Here's why it would be good if you can provide other specifiers:
:DESC is a useful starting point for the CNA to write the candidate's
description. If you intend to be a CNA yourself or provide new
submissions, it's good "practice" to provide one.
:APPNAME helps to reduce the data integration effort. The application
name dramatically reduces the number of possible matches that the
CNA will have to consider when searching the current CVE/candidate
information. This name might not always be possible for you to
obtain, depending on your database design.
:DETAILS are useful to provide additional information to the CNA in
case shorter descriptions are not sufficient.
:INTID is the submitter's own ID for the submission, e.g. record
number, database identifier, unique name, etc. It may be useful for
a "back-map" from submissions to candidate numbers. The CNA could
provide this back-map to the submitter to (a) facilitate the
submitter's voting and (b) provide a tangible benefit to a submitter
for their efforts, by "jump-starting" their mapping with links back
to candidate numbers.
Below are some legacy submissions as they might look like if it were
dumped directly from a vulnerability database without any further
"massaging" of the data.
:KEYWORDS phf, CGI, shell metacharacters
:SHORT phf vulnerability
:REF CERT advisory CA-96.06
The phf CGI program does not adequately strip shell metacharacters
from an input string. This allows an attacker to specify commands
which get executed during a system() call.
Patch the program or, even better, delete it from your cgi-bin
*NOTE* - the :DETAILS specifier is clearly from a "text dump" from a
larger text information source. You are *NOT* required to provide
risk assessment, fix information, etc.; this won't make it into CVE
This example was taken directly from a BindView advisory. Suppose
that BindView was the submitter.
:REF BINDVIEW:Falcon Web Server Technical Advisory
Falcon Web Server suffers from a path parsing problem, which allows a
remote user to escape out of the webroot directory. Also, the web
server gives up information about itself when certain filenames are
The Falcon Web Server (FWS) is a fully functional web server meant for
running on desktop computers, handling about 50 to 80 hits per minute.
The Falcon Web Server is plagued by a path parsing bug which has
affected other web servers in the past, such as old IIS and Apache. This
bug allows a remote user to "break out" of the webroot directory, where
the web server runs, and browse directories and/or download files from
areas outside of the webroot directory.
The default settings of the web server allow browsing of directories and
reading of files outside the webroot directory. Users can disable this
"feature." If it is disabled, one can still read the files, but the
complete path must be known to the attacker.
FWS also has a bug in handling long file name requests, in which it will
give up the location of the webroot directory. This can be used as a
information gathering technique for further attacking of the machine.
This example was taken directly from an ISS summary. Suppose that ISS
was the submitter.
:SHORT WebTrends MAPI permissions
Platforms Affected: WebTrends
Risk Factor: High
Attack Type: Network Based
X-Force has discovered a security hole in many WebTrends products that
allows access to service account and MAPI usernames and passwords.
WebTrends specializes in providing enterprise management solutions
software. The vulnerability only applies to systems using the MAPI and NT
service features in the following or earlier versions of the applications
currently identified as vulnerable by ISS X-Force: WebTrends for Firewalls
v1.2, WebTrends Security Analyzer v2.0, WebTrends Professional Suite
v3.01, WebTrends Log Analyzer v4.51, and WebTrends Enterprise Suite v3.5.
All applications run on the Windows NT platform.
ISS Security Advisory: "Bad Permissions on Passwords Stored by WebTrends
Software" at: http://xforce.iss.net/alerts/advise29.php3
This example was taken directly from a Security Focus summary.
Suppose that Security Focus was the submitter.
:SHORT IDEA BO2k Plug-in Identical Key Vulnerability
3. IDEA BO2k Plug-in Identical Key Vulnerability
Date Published: 08/04/99
The IDEA encryption plug-in for BO2k version 0.3 has a flaw which causes
any password to generate the same key.Maw~ has released version 0.4 which
does not have this vulnerability. It is available at: