Скачать презентацию CVE Behind the Scenes The Complexity of Being
a2e4e08d17ce461b840c69b0365ee74a.ppt
- Количество слайдов: 41
CVE Behind the Scenes: The Complexity of Being Simple Steve Christey The MITRE Corporation July 11, 2001 © 2001 The MITRE Corporation MITRE
2 Common Vulnerabilities and Exposures (CVE) 0 0 0 0 0 CVE at a glance Criteria for a good CVE submission stage Content decisions CVE candidate stage Reserving candidate numbers CVE entry stage Comments on CVE names Top 10 vulnerability types Managing diverse perspectives MITRE
3 CVE at a Glance CVE-1999 -0067 Description: CGI phf program allows remote command execution through shell metacharacters. References: CERT: CA-96. 06. cgi_example_code XF: http-cgi-phf BID: 629 http: //cve. mitre. org MITRE
4 CVE Enables Detailed Product Comparisons 0 CVE can normalize how vulnerabilities are counted 0 But how should it normalize them? MITRE
5 Using CVE in the Enterprise My scanner can’t find CVE-3, and I need patches for CVE-1 I need to fix these vulnerabilities Security Bulletins Vulnerability Scanner CVE-1 CVE-2 CVE-3 CVE-1 CVE-2 Attack CVE-3 CVE-1 Attack CVE-2 CVE-1 is on my network Attack CVE-1 Attacks • CVE-1: that system is not vulnerable, so don’t send an alert • CVE-2: my scanner must work well • CVE-3: my IDS must work well CVE-1 CVE-3 Web Sites IDS My IDS can’t detect attacks on CVE-2 MITRE
6 Criteria for a Good CVE 0 From “Towards a Common Enumeration of Vulnerabilities” (Mann/Christey, 2 nd 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 3. Be publicly "open" and shareable without distribution restrictions 4. Exist independently of the multiple perspectives of what a vulnerability is 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) Response Teams Ken Armstrong - Can. CERT Bill Fithen - CERT/CC Shawn Hernan - CERT/CC Scott Lawler - DOD-CERT John Rhodes - DOE-CIAC Tool Vendors Andy Balinsky - Cisco Scott Blake - Bind. View Tim Collins - NFR Renaud Deraison - Nessus John Flowers - n. Circle Andre Frech - ISS Kent Landfield - info. Assure Jim Magdych - NAI David Mann - Bind. View Craig Ozancin - AXENT Paul Proctor - Cyber. Safe Mike Prosser - Symantec Marcus Ranum - NFR Tom Stracener - n. Circle Bill Wall - Harris Kevin Ziese - Cisco Academic/Educational Matt Bishop - UC Davis Computer Security Lab Eric Cole - SANS Pascal Meunier - Purdue University CERIAS Alan Paller - SANS Institute Gene Spafford - Purdue University CERIAS OS Vendors Troy Bollinger - IBM Casper Dik - Sun David Le. Blanc - Microsoft MITRE Dave Baker, Steve Christey, Bill Hill Information Providers Russ Cooper - NTBugtraq Elias Levy - Bugtraq, Security Focus Peter Mell - NIST Ron Nguyen - Ernst and Young Ken Williams - e. Security. Online. com Other Security Experts Kelly Cooper - GTE Internetworking Steve Northcutt - SANS Larry Oliver - IBM Adam Shostack - Zero-Knowledge Systems Stuart Staniford - Silicon Defense http: //cve. mitre. org/board/ MITRE
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 Vulnerability definitions vary widely! Criterion #1: Enumerate and discriminate between all known vulnerabilities MITRE
10 Issue: What is a Real Vulnerability? 0 ~50% of all issues are not publicly acknowledged by the vendor 0 0 – http: //cve. mitre. org/board/archives/2000 -09/msg 00038. html Many vulnerabilities are found in obscure software by unknown researchers without independent confirmation Resource-intensive to verify every report Many sources focus on comprehensiveness and timeliness 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? 0 Extreme example CAN-1999 -0205 Denial of service in Sendmail 8. 6. 11 and 8. 6. 12 – Could not be replicated by vendor – Checked by multiple tools (which may only compare banners) Criterion #1: Enumerate and discriminate between all known vulnerabilities MITRE
11 Issue: What is a Known Vulnerability? 0 Only include “publicly known” vulnerabilities 0 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 Criterion #1: Enumerate and discriminate between all known vulnerabilities MITRE
12 Identifying Known Vulnerabilities: The CVE Submission Stage 0 Sources provide MITRE with their lists of all known vulnerabilities 0 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 Criterion #1: Enumerate and discriminate between all known vulnerabilities MITRE
13 Submission Conversion • 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 Source A Source B • Well-formatted text • Uses symbolic ID’s A: 2 A: 1 iis-dos ftp-pasv B: 1 B: 2 A: 3 A: 4 sendmail-headers cgi-overflow A: 5 • Excel spreadsheet • Uses numeric ID’s (row number) 17 179 B: 4 B: 3 29 524 Source C • Web page • Uses numeric ID’s C: 1 C: 2 19 23 C: 4 C: 3 21 46 cde-privilege-drop Criterion #1: Enumerate and discriminate between all known vulnerabilities MITRE
14 Normalizing Keywords • Convert description, short name, references into keywords • Periods, hyphens, etc. are NOT treated as word separators • Standardize keywords using thesaurus Raw Submission CVE Thesaurus buffer overflow buffer overrun pfdispaly pfdisplay Normalized Submission wuftpd wu-ftpd internet_explorer Normalizer wuftp IE MSIE IE 4 • 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! Criterion #1: Enumerate and discriminate between all known vulnerabilities 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 Match: A: 1 iis-dos C: 4 C: 2 21 23 B: 3 524 B: 2 179 CAN-1999 -1234 Match: B: 1 C: 2 B: 3 B: 1 A: 1 23 524 17 iis-dos 17 A: 2 ftp-pasv CAN-1999 -1234 Match: C: 1 19 A: 3 sendmail-headers CVE-1999 -1547 Criterion #1: Enumerate and discriminate between all known vulnerabilities MITRE
16 Submission Refinement • 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 B: 3 524 A: 1 iis-dos B: 1 C: 1 17 CAN-1999 -1234 19 A: 2 ftp-pasv • Verify that submissions are duplicates of the candidate (or entry) • Collect references • Write description • Apply content decisions Submissions with CVE names could reduce much of this effort! Criterion #1: Enumerate and discriminate between all known vulnerabilities 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 = = 0 0 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 Understanding unique, application-specific vulnerabilities Managing the volume of information Writing a good description (compact but with the right keywords) Writing and following good consistency rules Criterion #1: Enumerate and discriminate between all known vulnerabilities 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! Criterion #1: Enumerate and discriminate between all known vulnerabilities MITRE
19 Example Content Decision: SF-LOC (Software Flaws/Lines of Code) Create separate entries for problems in the same program that are of different types, or that appear in different software versions. 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 record 0 Affected by amount of available information – Especially source code and exploit details 0 For all candidates affected by SF-LOC, see: – http: //cve. mitre. org/cgi-bin/cvekey. cgi? keyword=CD: SF-LOC Criterion #1: Enumerate and discriminate between all known vulnerabilities MITRE
20 SF-LOC Examples CAN-2000 -0686 Auction Weaver CGI script 1. 03 and earlier allows remote attackers to read arbitrary files via a. . (dot dot) attack in the fromfile parameter. 2 failure points 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. 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-2001 -0019 Arrowpoint (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-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 6 failure points 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 Criterion #1: Enumerate and discriminate between all known vulnerabilities MITRE
21 Why CAN-2001 -0019 Could Identify 1, 2, or 6 Vulnerabilities 0 3 different source code scenarios 0 Without actual source, can’t be sure which scenario is true 0 Even with source, there are different ways of counting 0 Multiple format string problems are especially difficult to distinguish 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); } if (strcmp(cmd, "show") == 0) { if (strcmp(arg 1, "script") == 0) { strcpy(str, long_input); show_script(str); } elsif (strcmp(arg 1, "archive") == 0) { strcpy(str, long_input); show_archive(str); } elsif (strcmp(arg 1, "log") == 0) { strcpy(str, long_input); show_log(str); } } elsif (strcmp(cmd, "clear") == 0) { if (strcmp(arg 1, "script") == 0) { strcpy(str, long_input); show_script(str); } elsif (strcmp(arg 1, "archive") == 0) { strcpy(str, long_input); show_archive(str); } elsif (strcmp(arg 1, "log") == 0) { strcpy(str, long_input); show_log(str); } } Criterion #1: Enumerate and discriminate between all known vulnerabilities MITRE
22 Example Content Decision: SF-EXEC (Software Flaws in Multiple Executables) If the same flaws appear in multiple executables in the same package at the same time, then combine them into a single entry. 0 Could be a cut-and-paste error, or use of library code 0 Example CVE-1999 -0068 CGI PHP mylog script allows an attacker to read any file on the target server CVE-1999 -0346 CGI PHP mlog script allows an attacker to read any file on the target server 0 Both scripts had a vulnerable “
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 DDo. S 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. Criterion #1: Enumerate and discriminate between all known vulnerabilities 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 -0096 Buffer overflow in qpopper 3. 0 beta versions allows local users to gain privileges via a long LIST command. CAN-2000 -0046 Buffer overflow in ICQ 99 b 1. 1 client allows remote attackers to execute commands via a malformed URL within an ICQ message. 0 EX-DOS-CLIENT: “Exclude denial of service problems in clients unless the Do. S extends beyond the client itself. ” CAN-2000 -0190 AOL Instant Messenger (AIM) client allows remote attackers to cause a denial of service via a message with a malformed ASCII value. – But what if a buffer overflow causes the Do. S? CAN-2000 -0756 Microsoft Outlook 2000 does not properly process long or malformed fields in v. Card (. vcf) files, which allows attackers to cause a denial of service. CAN-2001 -0145 Buffer overflow in VCard handler in Outlook 2000 and 98, and Outlook Express 5. x, allows an attacker to execute arbitrary commands via a malformed v. Card birthday field. Criterion #1: Enumerate and discriminate between all known vulnerabilities MITRE
Criterion #2: Assign a standard, unique name to each vulnerability MITRE
26 Candidate Stage: Assignment CAN-YYYY-NNNN B: 1 C: 1 17 • Assign new number (CAN-YYYY-NNNN) • YYYY is the year in which the number was assigned; NNNN is a counter for that year 19 To Source A ftp-pasv = CAN-YYYY-NNNN iis-dos = CAN-1999 -1234 A: 2 ftp-pasv CAN-1999 -1234 B: 3 524 Backmap To Source B 17 = CAN-YYYY-NNNN 524 = CAN-1999 -1234 To Source C 19 = CAN-YYYY-NNNN A: 1 iis-dos • 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 researchers 0 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. Criterion #2: Assign a standard, unique name to each vulnerability MITRE
28 Candidate Reservation Process Researcher Request Candidate CAN-YYYY-NNNN • 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 Candidate Numbering Authority CAN POOL • 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 MITRE • Primary CNA • Accessible to researchers via [email protected] org • Educate CNA about content decisions • Update CVE web site when candidate is publicly announced • Track potential abuses Criterion #2: Assign a standard, unique name to each vulnerability MITRE
29 Know something? Gonna tell everyone? Get a CAN! [email protected] org Criterion #2: Assign a standard, unique name to each vulnerability MITRE
30 Candidate Stage: Proposal Through Final Decision CAN-YYYY-NNNN Proposal Modification • 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 • Add references, change description • Change level of abstraction • Significant changes may require another round of voting Interim Decision • ACCEPT or REJECT (Requires sufficient votes) • At least 2 weeks after initial proposal • 4 days for last-minute feedback Final Decision • ACCEPT or REJECT • Convert CAN-YYYY-NNNN to CVE-YYYY-NNNN • Report final voting record • Create new CVE version Criterion #2: Assign a standard, unique name to each vulnerability MITRE
31 Entry Stage CVE-YYYY-NNNN Publication • Publish new CVE version and difference report Modification • Minor modifications • Add references • Change description Reassessment • 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 Deprecation • 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 Criterion #2: Assign a standard, unique name to each vulnerability MITRE
32 CVE Growth Status (as of May 28, 2001) • 1510 entries • 1120 candidates Criterion #2: Assign a standard, unique name to each vulnerability 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-10 K 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. Criterion #2: Assign a standard, unique name to each vulnerability MITRE
Criterion #3: Be publicly open and shareable, without distribution restrictions MITRE
35 What’s Open 0 0 0 Editorial Board mailing list archives and meeting summaries Candidate votes and comments from Board members Mailing lists available for CVE news and data updates Various download formats 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, Open. BSD, Su. SE, 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) 1540 total CVE entries and candidates analyzed (yes, that’s 100 per month) CVE content decisions directly affect these statistics. Criterion #3: Be publicly open and shareable, without distribution restrictions MITRE
37 Education of a Vulnerability Analyst (In 3 Acts) 0 The early days: Insufficient details to discriminate between similar vulnerabilities CVE-1999 -0032 Buffer 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 -0039 Alta. Vista search engine allows remote attackers to read files above the document root via a. . (dot dot) in the query. cgi CGI program. CVE-2000 -0573 The 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 -0443 Buffer 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. Criterion #3: Be publicly open and shareable, without distribution restrictions MITRE
Criterion #4: Exist independently of the multiple perspectives of what a vulnerability is MITRE
39 Some Perspectives Perfectionist New First Catch up on older problems before focusing on new ones Fast and furious, Give me CAN’s and fix things for new issues later Slow and steady, ASAP get it right the first time Include Wireless Telecom Speed Demon One CVE per patch Give me And nothing One CVE everything I Legacy don’t Focus First per bug I on CVE want Compatibility Use strong Based Academic on my theoretical own Researcher needs Miscellaneous principles Include Fix info Sysadmin Everyone Include And Confidence. Change the Risk XML Levels. Naming Scheme Levels Format Focus on CVE Compatibility Or at the Security latest, now Manager Traditionalist Anti. Exclude insecure Admin Only include software flaws configurations Include Viruses Exploits Attacks Signatures Yesterday Include whatever may conflict with security policy IDS Scanner Criterion #4: Exist independently of the multiple perspectives of what a vulnerability is MITRE
40 Managing Perspectives Consult the Editorial Board Grow a thick skin Listen to the users CVE Please everyone some of the time Re-prioritize when possible Maximize utility Document and educate when you can Criterion #4: Exist independently of the multiple perspectives of what a vulnerability is MITRE
41 For More Information http: //cve. mitre. org MITRE