[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[CVEPRI] Reminder: Top 100/Six Month lists due November 15

All:

As a reminder, I'd like to get everyone's list of top 100 items they'd
like to see in CVE, and/or the list of problems that have been
discovered in the last six months.

I've extended the "deadline" until Monday, September 15.  While it's
not a hard deadline, please try to meet it; otherwise we run the risk
of not having sufficient time to reach the goal of 500 entries by Y2K.

For convenience, I've included the CSF submission format for you to
submit your information.


Thanks,
- Steve



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
previous email.

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.


Terminology
-----------

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
candidate.

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.


Copyright Concerns
------------------

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).


Specifiers
----------

<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
                                  additional information

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
duplicates.


:LEGACY
[:SHORT | :DETAILS | :DESC]+
:END

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:

:REF
: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.


Example Submissions
------------------

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.


Submission 1
------------

:LEGACY
:KEYWORDS phf, CGI, shell metacharacters
:SHORT phf vulnerability
:APPNAME phf
:REF http://www.securityfocus.com/BUGTRAQ_ARTICLE_URL
:REF CERT advisory CA-96.06
:INTID phf
:DETAILS
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.

Risk: High

Fix:
Patch the program or, even better, delete it from your cgi-bin
directory.

:END

*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
 anyway.



Submission 2
------------

This example was taken directly from a BindView advisory.  Suppose
that BindView was the submitter.

:LEGACY
:REF BINDVIEW:Falcon Web Server Technical Advisory
:DESC

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
requested.

:DETAILS
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.

:END




Submission 3
------------

This example was taken directly from an ISS summary.  Suppose that ISS
was the submitter.

:LEGACY
:REF XF:webtrends-bad-perms
:INTID webtrends-bad-perms
:SHORT WebTrends MAPI permissions
:DETAILS

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.

Reference:
ISS Security Advisory: "Bad Permissions on Passwords Stored by WebTrends
Software" at: http://xforce.iss.net/alerts/advise29.php3

:END



Submission 4
------------

This example was taken directly from a Security Focus summary.
Suppose that Security Focus was the submitter.


:LEGACY
:REF BUGTRAQID:562
:SHORT IDEA BO2k Plug-in Identical Key Vulnerability
:DETAILS

3. IDEA BO2k Plug-in Identical Key Vulnerability
Remote: Yes
Date Published: 08/04/99
Relevant URL:
http://www.securityfocus.com/level2/?go=vulnerabilities&id=562
Summary:

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:

http://www.wynne.demon.co.uk/maw/

:END
Page Last Updated or Reviewed: May 22, 2007