1 / 30

The Vulnerabilities Project

The Vulnerabilities Project. Matt Bishop Department of Computer Science University of California at Davis Davis, CA 95616-8562 email : bishop@cs.ucdavis.edu url : http://seclab.cs.ucdavis.edu/~bishop phone : (530) 752-8060 fax : (530) 752-4767. Shhhh. Three can keep a secret …

misha
Download Presentation

The Vulnerabilities Project

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Vulnerabilities Project Matt Bishop Department of Computer Science University of California at Davis Davis, CA 95616-8562 email: bishop@cs.ucdavis.edu url: http://seclab.cs.ucdavis.edu/~bishop phone: (530) 752-8060 fax: (530) 752-4767 VP/07241998

  2. Shhhh... Three can keep a secret … … if two of them are dead. VP/07241998

  3. Outline • Review project goals • Status of vulnerabilities database • Status of analysis technique • A few other things … VP/07241998

  4. Project Goals • To present techniques for finding these vulnerabilities • To present techniques to inhibit or eliminate exploitation of those vulnerabilities VP/07241998

  5. More Project Goals • To exhibit similarities between instances of vulnerabilities • To provide a history so we learn from past mistakes • To describe the vulnerabilities in a form useful to intrusion detection mechanisms VP/07241998

  6. History • Dynamic load path problem (1993-current) • Same as PATH problem (found 1981) • Buffer overflow problem (1993-current) • Same as fingerd exploit of Internet Worm (1988); variant of buffer overflow problem in UNIX login program (ca. 1978) • UID size mismatch between OS and NIS (late 1980s) • Burroughs paging problem (early 1970’s) VP/07241998

  7. Getting There From Here Hypothesis: Vulnerabilities occur when a set of conditions hold. If the conditions making up the set are primitive, then invalidating any of the conditions eliminating the vulnerability. Further, the primitives are common to multiple systems (with appropriate superficial modifications). VP/07241998

  8. Implications of the Hypothesis • You can find vulnerabilities by looking for the presence of sets of primitives in a system • You can eliminate vulnerabilities you do not know about by invalidating primitive conditions (which eliminates all vulnerabilities with that primitive) • This induces a simple taxonomy with a metric for the difference between vulnerabilities (eg., Hamming distance) VP/07241998

  9. Testing the Hypothesis • Ideally, find a formal derivation of primitives • More on this in a bit • Experimentally, test all the vulnerabilities you can find on as many systems as possible • Our initial approach • First is better but more difficult; second is vital because it captures the way most sites, systems treat security • That is, informally … VP/07241998

  10. DOVES • Database Of Vulnerabilities, Exploits, and Signatures • Vulnerabilities for hypothesis testing • Attacks for analyzing, verifying vulnerabilities • Signatures for intrusion detection systems VP/07241998

  11. What DOVES Entries Looks Like • Version #1: 1993-1997 • Refer format, printed using PERL scripts which translated it into TeX input • Version #2: 1997- • SGML format • Portion of the database to be available over the Internet (in HTML and edited) VP/07241998

  12. Why SGML? • Focuses on content, not formatting • Extensible; easy to add elements, attributes • SGML widely used in electronic document processing • International standard VP/07241998

  13. Other Good Things About SGML • Easy to preprocess • So if we want to make it input for other tools, such as an Oracle database, we can do so easily • Same document represented differently • HTML, RTF, MIF, ASCII, XML, etc. from a FOSI or DSSSL back-end (we use jade, which implements a subset of DSSSL) VP/07241998

  14. Current Fields: Vulnerabilities • Vulnerability description • Name, description, program & components, versions, OS version(s), other relevant information (such as environment), effect, how to detect and fix it (administratively and technically, if possible) • Attacks exploiting this vulnerability • Genealogy • Who first reported it, where & when, cross-references, dates, documents, advisories VP/07241998

  15. Example Database Entry <!DOCTYPE vdbentry SYSTEM "vulner.dtd"> <vdbentry> <vdesc> <name><prog mansec=8>crash</prog> &setgid; permissions and kernel browsing</name> <short><prog>Crash</prog> was designed to allow kernel core analysis. It is executable by anyone and &setgid; to group <group>sys</group>. <long>…</long> <comp><prog>crash</prog></comp> VP/07241998

  16. Example Database Entry <vers>all versions</vers> <os>verified: &sunos411;, unverified: &bsd4x;, &sol2x;</os> <vother>All states</vother> <veffect>Kernel structures once thought readonly by members of the group <group>sys</group> become readable by any user.</veffect> </vdesc> . . . </vdbentry> VP/07241998

  17. Status • Building it • Sources: 2 older databases, bugtraq, nt-bugtraq, others • Can handle sensitive vulnerabilities too • Total: 60 vulnerabilities in this form • 120+ more entries from older databases • UNIX (many variants), network, Windows NT vulnerabilities (more UNIX ones, Windows catching up rapidly) VP/07241998

  18. Exploits Portion • Attack tools • May be many different ones exploiting the same vulnerability, so we keep them separate • We try to debug them as we can • Not a very high priority • Source of tool kept • Point to vulnerability(-ies) involved VP/07241998

  19. Attack Tools: Fields • Attack description • Name, vulnerability(ies), systems, required tools, environment, network configuration(s), other • Effects • Any effects beyond the exploit, detecting the use, blocking the use • Genealogy • Who wrote it, where & when, cross-references to other attack tools, dates, documents VP/07241998

  20. Status • Collecting them for new vulnerabilities • No validation done of new ones, so not yet entered into database • Pointer to tool from corresponding vulnerability (so we don’t have to figure it out) • Ones from older database already validated, so will be first put in • Some of these are highly portable (Michael Dilger was a good hacker) VP/07241998

  21. Plans • Library of tested attack tools • Need more systems for this • Upgrade and improve isolated network • Clumsy to do experiments (too much reconfiguration and recabling) • Build Windows, X, WWW interfaces • Make the database easy to search VP/07241998

  22. Intentions • Release vulnerability information to researchers, sponsors, etc. for free • Parts will go on the web • Idea is to provide others with information they can use in their research • Will ask (require?) commercial users to give support • Attack information tightly controlled • Not on web VP/07241998

  23. Expected Time Line • Release #1: end of September • Will contain vulnerability data only; sanitized to web, unsanitized to isonet and CD • Release #2 • Will contain attack tools also, but those won’t be on the web and recipients will be asked not to put them there! VP/07241998

  24. Parlez-vous français? • Vocabulary to describe vulnerabilities depends on background of user • Universally agreed-upon vocabulary highly unlikely • Relationship of terms may not be clear to a developer who is not an expert in the nature of vulnerabilities (or knows very little about security!) VP/07241998

  25. Thesaurus • Answer: create a thesaurus • Organizes terms to enable classifier or user to find related terms quickly • Independent of organization of data Approach suggested by Mike Raugh of Interconnect Technologies; work done with him, Vicky Johnson, Diane Hillmann of the Technical Support Services, Olin Library, Cornell University and a member of Machine-Readable Bibliographic Information Committee of the American Library Association VP/07241998

  26. Formal Methods • State security requirements or policy as a set of constraints • Negations of the constraints form primitives • Rationale: vulnerabilities are violations of policy, e.g., policy constraints • Needed: a technique to rigorously perform the breakdown from constraints to primitives VP/07241998

  27. Future Work • Expand database • The more we get, the better we can test our hypothesis • Pursue decomposition techniques • Develop primitives for multiple systems • Our experience is that they will be pretty much the same, but we still must verify this … VP/07241998

  28. Pedagogy • How to design operational procedures that invalidate primitives • How to write programs that invalidate primitives • security-related coding practices • ECS 153, Intro to Computer Security VP/07241998

  29. Weinberg’s Second Law If builders built buildings like programmers wrote programs … then the first woodpecker to come along would destroy civilization VP/07241998

  30. More Information • Project URL • http://seclab.cs.ucdavis.edu/projects/vulnerabilities • Project assistant’s email • vp-info@cs.ucdavis.edu • Fellow participants • Ricardo Anguiano, Mark Dilger, Michael Dilger*, Todd Heberlein*, Keith Herold, Karl Levitt, David O’Brien, Steven Samorodin*, Alex Smith*, Scot Templeton* … and others * means alumnus or alumna VP/07241998

More Related