1 CVE Behind the Scenes: The Complexity of Being Simple Steve Christey The MITRE Corporation July 11, 2001 © 2001 The MITRE Corporation

MITRE

1

CVE Behind the Scenes:The Complexity of Being Simple

Steve ChristeyThe MITRE Corporation

July 11, 2001

© 2001 The MITRE Corporation

MITRE

2

Common Vulnerabilities and Exposures (CVE)

0 CVE at a glance0 Criteria for a good CVE0 CVE submission stage0 Content decisions0 CVE candidate stage0 Reserving candidate numbers0 CVE entry stage0 Comments on CVE names0 Top 10 vulnerability types0 Managing diverse perspectives

MITRE

3

CVE at a Glance

Organization Name

CERT CA-96.06.cgi_example_code

CyberSafe Network: HTTP ‘phf’ Attack

ISS http-cgi-phf

AXENT phf CGI allows remote command execution

Bugtraq PHF Attacks – Fun and games for the whole family

BindView #107 – cgi-phf

Cisco #3200 – WWW phf attack

IBM ERS Vulnerability in NCSA/Apache Example Code

CERIAS http_escshellcmd

NAI #10004 - WWW phf check

Description:CGI phf program allows remote command execution through shell metacharacters.

References:CERT:CA-96.06.cgi_example_codeXF:http-cgi-phfBID:629

CVE-1999-0067

http://cve.mitre.org

MITRE

4

CVE Enables Detailed Product Comparisons

CVEName

ToolA

ToolB

DB1

DB2

HackerAttacks

CVE-XXXX-0001 X X X

CVE-XXXX-0002 X X X

CVE-XXXX-0003 X X

CVE-XXXX-0004 X X X X

0 CVE can normalize how vulnerabilities are counted0 But how should it normalize them?

MITRE

5

Using CVE in the Enterprise

SecurityBulletins

CVE-1CVE-2CVE-3

WebSites

CVE-3

IDS

CVE-1CVE-3

VulnerabilityScanner

CVE-1CVE-2

My IDS can’t detect attacks on CVE-2

My scanner can’t find CVE-3,and I need patches for CVE-1

CVE-1 is on my network

I need to fix thesevulnerabilities

CVE-1

Attacks

Attack CVE-3

•CVE-3: my IDS must work well

Attack CVE-2

•CVE-2: my scanner must work well

Attack CVE-1

•CVE-1: that system is not vulnerable, so don’t send an alert

MITRE

6

Criteria for a Good CVE

0 From “Towards a Common Enumeration of Vulnerabilities” (Mann/Christey, 2nd Workshop on Research with Security Vulnerability Databases, Purdue, January 21-22, 1999)

1. Enumerate and discriminate between all known vulnerabilities

2. Assign a standard, unique name to each vulnerability

4. Exist independently of the multiple perspectives of what a vulnerability is

3. Be publicly "open" and shareable without distribution restrictions

0 Evolving design considerations– Be as simple as possible

= Minimize workload and overlap with databases– Support the lookup of CVE names– Involve diverse players across the security community

MITRE

7

CVE Editorial Board Members(As of June 4, 2001)

Tool VendorsAndy Balinsky - CiscoScott Blake - BindViewTim Collins - NFRRenaud Deraison - NessusJohn Flowers - nCircleAndre Frech - ISSKent Landfield - infoAssureJim Magdych - NAIDavid Mann - BindViewCraig Ozancin - AXENTPaul Proctor - CyberSafeMike Prosser - SymantecMarcus Ranum - NFRTom Stracener - nCircleBill Wall - HarrisKevin Ziese - Cisco

Academic/EducationalMatt Bishop - UC Davis Computer Security LabEric Cole - SANSPascal Meunier - Purdue University CERIASAlan Paller - SANS InstituteGene Spafford - Purdue University CERIAS

MITREDave Baker, Steve Christey, Bill Hill

Other Security ExpertsKelly Cooper - GTE InternetworkingSteve Northcutt - SANSLarry Oliver - IBMAdam Shostack - Zero-Knowledge SystemsStuart Staniford - Silicon Defense

Response TeamsKen Armstrong - CanCERTBill Fithen - CERT/CCShawn Hernan - CERT/CCScott Lawler - DOD-CERTJohn Rhodes - DOE-CIAC

Information ProvidersRuss Cooper - NTBugtraqElias Levy - Bugtraq, Security FocusPeter Mell - NISTRon Nguyen - Ernst and YoungKen Williams - eSecurityOnline.comOS Vendors

Troy Bollinger - IBMCasper Dik - Sun David LeBlanc - Microsoft

http://cve.mitre.org/board/

MITRE

8

Criterion #1:Enumerate and discriminate

between all known vulnerabilities

MITRE

9

Issue: What is a Vulnerability?

0 CVE was originally called “Common Vulnerability Enumeration”0 Security tools included many “non-vulnerabilities”0 “Terminological warfare” by Editorial Board in August 1999

– 2 main debates= What is a vulnerability?= Should CVE include things that aren’t vulnerabilities?

– Primary example: running finger (CVE-1999-0612)= “Stepping stone” but not directly exploitable

– Various alternate terms were debated– “Exposure” wasn’t being used that often back then, and there

was a strong need to keep the CVE acronym, so...0 See:

– http://cve.mitre.org/about/terminology.html– http://cve.mitre.org/board/archives/1999-08/threads.html

Criterion #1: Enumerate and discriminate between all known vulnerabilities

Vulnerability definitions vary widely!

MITRE

10

0 Extreme example

– Could not be replicated by vendor– Checked by multiple tools (which may only compare banners)

Issue: What is a Real Vulnerability?

0 ~50% of all issues are not publicly acknowledged by the vendor– http://cve.mitre.org/board/archives/2000-09/msg00038.html

0 Many vulnerabilities are found in obscure software by unknown researchers without independent confirmation

0 Resource-intensive to verify every report0 Many sources focus on comprehensiveness and timeliness0 If it’s reported but it may not be real, should it be added to CVE?

– It will at least be reviewed– How much verification is necessary?


CAN-1999-0205 Denial of service in Sendmail 8.6.11 and 8.6.12

MITRE

11

Issue: What is a Known Vulnerability?

0 Only include “publicly known” vulnerabilities0 Rely on data sources to provide MITRE with vulnerability lists

– 10 sources for legacy issues (1999 and earlier)= 8500 total items provided

– 4 periodic vulnerability summaries used for new issues– See http://cve.mitre.org/cve/datasources.html for details

0 Some vulnerabilities are not announced through normal public sources that allow peer review


MITRE

12

Identifying Known Vulnerabilities:The CVE Submission Stage

0 Sources provide MITRE with their lists of all known vulnerabilities0 MITRE’s CVE Content Team processes submissions


Conversion• Convert items in database/tool to submission format• Assign temporary ID’s to each submission

Matching• Find most similar submissions, candidates, and entries

based on keywords

Refinement• Combine all matched submissions into groups• Use each group to create candidates

MITRE

13

Submission Conversion

A:1iis-dos

Source A• Well-formatted text• Uses symbolic ID’s

A:2ftp-pasv

A:3sendmail-headers

A:4cgi-overflow

A:5cde-privilege-drop

• Data format is often unique to the sources• Specialized scripts convert a source to standard submission format• Extract description, references, source’s own unique identifiers

• Excel spreadsheet• Uses numeric ID’s

(row number)

Source B

B:117

B:2179

B:3524

B:429

• Web page• Uses

numeric ID’s

Source C

C:119

C:223

C:346

C:421


MITRE

14

Normalizing Keywords

• Maps similar terms to a single, standard term

• Reduce chance of missing a match

• Example: “pfdisplay”•A common mistake since the misspelled word is the actual name of the program!

CVEThesaurus

buffer overrunbuffer overflow

pfdisplaypfdispaly

wuftpdwu-ftp

wu-ftpdwuftp

IEMSIEIE4

internet_explorer

RawSubmission

• Convert description, short name, references into keywords

• Periods, hyphens, etc. are NOT treated as word separators

• Standardize keywords using thesaurus

Normalizer

NormalizedSubmission


MITRE

15

Submission Matching

• Each submission is matched against all submissions, candidates, and entries•Information retrieval techniques provide list of 10 closest matches

• Metric favors rare keywords over common ones•Tends to favor application names and version numbers•Can overly favor “incidentally rare” terms

• Human marks which matches are correct

B:117

A:1iis-dos

A:3sendmail-headers

C:119

CVE-1999-1547

Match:A:1iis-dos

C:421

B:2179

Match:

C:223

B:3524

CAN-1999-1234 CAN-1999-1234

B:117

C:223

Match:

B:3524

A:2ftp-pasv


MITRE

16

Submission Refinement

A:1iis-dos

B:3524

CAN-1999-1234

• Verify that submissions are duplicates of the candidate (or entry)

B:117

C:119

A:2ftp-pasv

• Collect references• Write description• Apply content decisions

• Determine submission groups by inferring match relationships• B:1 = A:2 C:1 = B:1 (A:2, B:1, C:1)

• Ensure that submissions all describe same problem• Matching can be inaccurate

• Deep analysis is a bottleneck

Submissions with CVE names could reduce much of this effort!


MITRE

17

Some Challenges in Refinement

0 Identifying duplicate issues– Can be difficult to trace a problem in multiple software packages

back to a common codebase– Differences in reporting between researcher and vendor– Lack of sufficient details in advisories

= Even credits to a particular person aren’t always sufficient!= A problem when similar issues are discovered at the same time= Change logs can be vague= Diffs (when available) may not provide sufficient context

– Delays between initial discovery and advisory– Rediscoveries of previously reported problems

0 Understanding unique, application-specific vulnerabilities0 Managing the volume of information0 Writing a good description (compact but with the right keywords)0 Writing and following good consistency rules


MITRE

18

Content Decisions

0 Explicit guidelines for content of CVE entries– Ensure and publicize consistency within CVE– Provide “lessons learned” for researchers– Document differences between vulnerability “views”

0 Three basic types– Inclusion: What goes into CVE? What doesn’t, and why?– Level of Abstraction: One or many entries for similar issues?– Format: How are CVE entries formatted?

0 Difficult to document– “[It’s] like trying to grasp wet corn starch” (Board member)


Incomplete information is the bane of consistency - and content decisions!

MITRE

19

Example Content Decision: SF-LOC(Software Flaws/Lines of Code)

0 Older versions of this CD distinguished between problems of the same type– “Split-by-default” approach generated “too many” candidates– Also “unfair” to vendors with source code or detailed reports– Once produced 8 candidates where other tools and databases

would have created only 1 vulnerability record0 Affected by amount of available information

– Especially source code and exploit details0 For all candidates affected by SF-LOC, see:

– http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=CD:SF-LOC


Create separate entries for problems in the same program that are of different types, or that appear in different software versions.

MITRE

20

SF-LOC Examples

0 CAN-2001-0019 is clearly different than CAN-2001-0020– But a single patch fixes both problems

0 CAN-2001-0019 could be 1, 2, or 6 vulnerabilities

CAN-2001-0020 Directory traversal vulnerability in Arrowpoint (aka Cisco Content Services, or CSS) allows local unprivileged users to read arbitrary files via a .. (dot dot) attack

CAN-2001-0019Arrowpoint (aka Cisco Content Services, or CSS) allows local users to cause a denial of service via a long argument to the “show script,” “clear script,” “show archive,” “clear archive,” “show log,” or “clear log” commands.

CAN-2000-0971 Avirt Mail 4.0 and 4.2 allows remote attackers to cause a denial of service and possibly execute arbitrary commands via a long "RCPT TO" or "MAIL FROM" command.

2 failure points

CAN-2000-0686Auction Weaver CGI script 1.03 and earlier allows remote attackers to read arbitrary files via a .. (dot dot) attack in the fromfile parameter.

CAN-2000-0687 Auction Weaver CGI script 1.03 and earlier allows remote attackers to read arbitrary files via a .. (dot dot) attack in the catdir parameter.

2 failurepoints

6 failurepoints


MITRE

21

Why CAN-2001-0019 Could Identify 1, 2, or 6 Vulnerabilities

if (strcmp(cmd, "show") == 0) { if (strcmp(arg1, "script") == 0) { strcpy(str, long_input); show_script(str); } elsif (strcmp(arg1, "archive") == 0) { strcpy(str, long_input); show_archive(str); } elsif (strcmp(arg1, "log") == 0) { strcpy(str, long_input); show_log(str); } }elsif (strcmp(cmd, "clear") == 0) { if (strcmp(arg1, "script") == 0) { strcpy(str, long_input); show_script(str); } elsif (strcmp(arg1, "archive") == 0) { strcpy(str, long_input); show_archive(str); } elsif (strcmp(arg1, "log") == 0) { strcpy(str, long_input); show_log(str); } }

strcpy(arg, long_input);if (strcmp(cmd, "show") == 0) { process_show_command(arg); }elsif (strcmp(cmd, "clear") == 0) { process_show_command(arg); }

if (strcmp(cmd, "show") == 0) { strcpy(str, long_input); process_show_command(str); }elsif (strcmp(cmd, "clear") == 0) { strcpy(str, long_input); process_clear_command(str); }

0 3 different source code scenarios0 Without actual source, can’t be sure

which scenario is true0 Even with source, there are different

ways of counting0 Multiple format string problems are

especially difficult to distinguish


MITRE

22

Example Content Decision: SF-EXEC(Software Flaws in Multiple Executables)

0 Could be a cut-and-paste error, or use of library code0 Example

CVE-1999-0346 CGI PHP mlog script allows an attacker to read any file on the target server

CVE-1999-0068 CGI PHP mylog script allows an attacker to read any file on the target server

0 Both scripts had a vulnerable “<include>” command that didn’t filter out bad characters– Should “include” have filtered the characters in the file name?– Or should they have been filtered before the include was called?

0 For all candidates affected by SF-EXEC, see:– http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=CD:SF-EXEC


If the same flaws appear in multiple executables in the same package at the same time, then combine them into a single entry.

MITRE

23

Other Example Abstraction CD’s

0 CF-PASS– Should there be one large entry for all default passwords?

= What about undocumented or back door passwords?= What about guessable passwords?

0 Other unnamed examples– Should separate entries be created for DDoS tools, Trojan

Horses, worms, and viruses?– How to handle insecure auditing settings, access permissions,

or privilege assignments? How to define “insecure”?– Is it the software application’s responsibility to restrict memory

usage, or is it the responsibility of the admin to use OS-specific parameters?


Abstraction content decisions directly impact CVE-based metrics, especially for configuration problems and malicious code.

MITRE

24

Example Inclusion CD’s

0 EX-BETA: “Exclude problems in beta products, unless the product is in permanent beta, or it has received wide distribution.”

CAN-2000-0096Buffer overflow in qpopper 3.0 beta versions allows local users to gain privileges via a long LIST command.

CAN-2000-0190AOL Instant Messenger (AIM) client allows remote attackers to cause a denial of service via a message with a malformed ASCII value.

CAN-2000-0046Buffer overflow in ICQ 99b 1.1.1.1 client allows remote attackers toexecute commands via a malformed URL within an ICQ message.

0 EX-DOS-CLIENT: “Exclude denial of service problems in clients unless the DoS extends beyond the client itself.”


– But what if a buffer overflow causes the DoS?

CAN-2000-0756Microsoft Outlook 2000 does not properly process long or malformed fields in vCard (.vcf) files, which allows attackers to cause a denial of service.

CAN-2001-0145Buffer overflow in VCard handler in Outlook 2000 and 98, and Outlook Express 5.x, allows an attacker to execute arbitrary commands via a malformed vCard birthday field.

MITRE

25

Criterion #2:Assign a standard, unique name to each vulnerability

MITRE

26

Backmap

Candidate Stage: Assignment

To Source B17 = CAN-YYYY-NNNN524 = CAN-1999-1234

To Source C19 = CAN-YYYY-NNNN

To Source Aftp-pasv = CAN-YYYY-NNNN

iis-dos = CAN-1999-1234

A:1iis-dos

B:3524

CAN-1999-1234

B:117

C:119

A:2ftp-pasv

CAN-YYYY-NNNN• Assign new number (CAN-YYYY-NNNN)• YYYY is the year in which the number was

assigned; NNNN is a counter for that year

• Backmap: internal ID’s mapped to candidate names, sent back to provider

• Submissions removed

Criterion #2: Assign a standard, unique name to each vulnerability

MITRE

27

Candidate Stage: Reservation

0 Candidate numbers can be reserved for inclusion in initial public announcements of vulnerabilities– Number is immediately available to all parties– Simplifies correlation and cross-referencing– Available to all researchers, vendors, and third parties

0 Current participants include well-known researchers, security vendors, and software vendors– ~150 candidates reserved since April 2000

0 Outreach being conducted to other vendors and researchers0 Candidate Numbering Authorities (CNA’s) are authorized to reserve

pools of candidate numbers from MITRE for other parties– Vendors or third parties


The candidate reservation process must be designed to minimize the impact on responsible vulnerability disclosure practices.

MITRE

28

Candidate Reservation Process

Researcher

• Request candidate from CNA• Provide candidate number to

vendor and other parties• Include candidate number in

initial public announcement• Notify MITRE of announcement• Perform due diligence to avoid

duplicate or incorrect candidates• Should work with affected vendor

to increase confidence in correctness of the candidate

CandidateNumberingAuthority

• Obtain pool of candidate numbers from MITRE

• Define requirements for researchers to obtain a candidate

• Assign correct number of candidate numbers

• Ensure candidate is shared across all parties

• Do not use candidates in “competitive” fashion

CANPOOL MITRE

• Primary CNA• Accessible to

researchers via [email protected]

• Educate CNA about content decisions

• Update CVE web site when candidate is publicly announced

• Track potential abuses

Request Candidate

CAN-YYYY-NNNN


MITRE

29

Know something?Gonna tell everyone?

Get a CAN!

[email protected]


MITRE

30

Candidate Stage: Proposal Through Final Decision

• Add references, change description• Change level of abstraction• Significant changes may require another round of voting

Modification

• ACCEPT or REJECT (Requires sufficient votes)• At least 2 weeks after initial proposal• 4 days for last-minute feedback

InterimDecision

• ACCEPT or REJECT• Convert CAN-YYYY-NNNN to CVE-YYYY-NNNN• Report final voting record• Create new CVE version

FinalDecision

• Clustering (date of discovery, OS, service type, etc.)• Published on CVE web site• Editorial Board members vote on candidate

•ACCEPT, MODIFY, REVIEWING, NOOP (No Opinion), RECAST (change level of abstraction), REJECT

Proposal

CAN-YYYY-NNNN


MITRE

31

Entry Stage

• Minor modifications• Add references• Change description

Modification

• New information may force a re-examination of the entry• Level of abstraction may need to be changed• May be a duplicate • May not be a problem after all

Reassessment

• May need to “delete” an existing entry (e.g. duplicate entries)• But, some products may still use this number• Register the “deletion” but keep entry available for review

Deprecation

• Publish new CVE version and difference reportPublication

CVE-YYYY-NNNN


MITRE

32

CVE Growth

Status(as of May 28, 2001)

• 1510 entries

• 1120 candidates


MITRE

33

What’s in a Name?

0 Some benefits with the current naming scheme– Compact– Candidate/entry status encoded within the name– Most CAN-YYYY-NNNN will become CVE-YYYY-NNNN– Removes debate about what a “good” name is

0 Some issues– Year segment can be misunderstood as year of discovery– Name is not atomic in most search engines, thus difficult to find– Changing a CAN to a CVE can incur maintenance costs– Maximum 10,000 candidates per year (CAN-10K problem)

0 Once public, names must not disappear without explanation– Deprecated entries, rejected candidates


Any change to the CVE naming scheme will impact many users.

MITRE

34

Criterion #3:Be publicly open and

shareable, without distribution restrictions

MITRE

35

What’s Open

0 Editorial Board mailing list archives and meeting summaries0 Candidate votes and comments from Board members0 Mailing lists available for CVE news and data updates0 Various download formats0 Reference maps from common sources to CVE names

– CERT/CC advisories, *Bugtraq posts, vendor bulletins, etc.

0 Challenges– Minimize potential “competition” with other information sources

= Can’t include confidence levels, OS, risk levels, etc.– Challenges by vendors– Documenting evolving approaches (e.g. content decisions)– Changing reference names or lack of clear advisory names

= Examples: Cisco, OpenBSD, SuSE, Debian– Translations into other languages– Managing expectations

Criterion #3: Be publicly open and shareable, without distribution restrictions

MITRE

36

Top Ten Vulnerability Types in CVE(Issues publicized between Jan 2000 and April 2001)

37

45

45

50

66

71

71

79

115

383

Trusted CGI Form Fields

Weak Encryption

Insecure Permissions

Format String

Symlink Following

Shell Metachars/Quoting

Unprotected Privileged Op's

Malformed Input DoS

Dir. Traversal/Dot Dot

Buffer Overflow

1540 total CVE entries and candidates analyzed(yes, that’s 100 per month)

CVE content decisions directly affect these statistics.


MITRE

37

Education of a Vulnerability Analyst(In 3 Acts)

0 The early days: Insufficient details to discriminate between similar vulnerabilities

CVE-1999-0032Buffer overflow in BSD-based lpr package allows local users to gain root privileges.

CVE-1999-0077 Predictable TCP sequence numbers allow spoofing.

0 The middle days: Dealing with emerging terminology

CVE-2000-0039AltaVista search engine allows remote attackers to read files above the document root via a .. (dot dot) in the query.cgi CGI program.

CVE-2000-0573The lreply function in wu-ftpd 2.6.0 and earlier does not properly cleanse an untrusted format string, which allows remote attackers to execute arbitrary commands via the SITE EXEC command.

0 Today: Include uncertainty, more details, support abstraction

CAN-2001-0443Buffer overflow in QPC QVT/Net Popd 4.20 in QVT/Net 5.0 allows remote attackers to cause a denial of service, and possibly execute arbitrary commands, via (1) a long username, or (2) a long password.


MITRE

38

Criterion #4:Exist independently of the

multiple perspectives of what a vulnerability is

MITRE

39

SecurityManager

AndRisk

Levels

IncludeConfidence

Levels

Focus onCVE

Compatibility

Some Perspectives

Speed Demon

Fast and furious,and fix things

later

Perfectionist

Slow and steady,get it right the

first time Legacy First

Catch up onolder problemsbefore focusing

on new ones

New First

Give me CAN’sfor new issues

ASAP

AcademicResearcher

One CVEper bug

Use strongtheoreticalprinciples

Sysadmin

One CVEper patch

IncludeFix info

Traditionalist

Only includesoftware flaws

Anti-Admin

Excludeinsecure

configurations

IDS

AttacksExploits Signatures

Scanner

Include whatevermay conflict with

security policy

Criterion #4: Exist independently of the multiple perspectives of what a vulnerability is

Miscellaneous

IncludeWireless

IncludeTelecom

IncludeVirusesXML

Format

Change theNaming Scheme

Focuson CVE

Compatibility

Everyone

Give meeverything I

want

And nothingI don’t

Based on myown needs

YesterdayOr at thelatest, now

MITRE

40

Managing Perspectives

CVE

Document andeducate when

you can

Maximizeutility

Consult theEditorial

Board

Grow athickskin

Please everyonesome of the time

Criterion #4: Exist independently of the multiple perspectives of what a vulnerability is

Listen tothe users Re-prioritize

whenpossible

MITRE

41

http://cve.mitre.org

For More Information

Documents

1 CVE Behind the Scenes: The Complexity of Being Simple Steve Christey The MITRE Corporation July 11, 2001 © 2001 The MITRE Corporation