Matt Bishop Computer Security Laboratory Dept. of Computer Science University of California at Davis...

VP/07241998 Slide # 1

Matt BishopComputer Security LaboratoryDept. of Computer ScienceUniversity of California at Davis

The Vulnerabilities Project

Matt BishopDepartment of Computer ScienceUniversity of California at Davis

Davis, CA 95616-8562

email: [email protected]: http://seclab.cs.ucdavis.edu/~bishop

phone: (530) 752-8060fax: (530) 752-4767

VP/07241998 Slide # 2


Shhhh...

Three can keep a secret …

… if two of them are dead.

VP/07241998 Slide # 3


Outline

• Review project goals• Status of vulnerabilities database• Status of analysis technique• A few other things …

VP/07241998 Slide # 4


Project Goals

• To present techniques for finding these vulnerabilities

• To present techniques to inhibit or eliminate exploitation of those vulnerabilities

VP/07241998 Slide # 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 Slide # 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 Slide # 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 Slide # 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 Slide # 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 Slide # 10


DOVES

• Database Of Vulnerabilities, Exploits, and Signatures– Vulnerabilities for hypothesis testing– Attacks for analyzing, verifying vulnerabilities– Signatures for intrusion detection systems

VP/07241998 Slide # 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 Slide # 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 Slide # 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 Slide # 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 Slide # 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 Slide # 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 Slide # 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 Slide # 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 Slide # 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 Slide # 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 Slide # 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 Slide # 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 Slide # 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 Slide # 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 Slide # 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 Slide # 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 Slide # 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 Slide # 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 Slide # 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 Slide # 30


More Information

• Project URL– http://seclab.cs.ucdavis.edu/projects/vulnerabilities

• Project assistant’s email– [email protected]

• 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

Matt Bishop Computer Security Laboratory Dept. of Computer Science University of California at Davis...

Documents

Transcript of Matt Bishop Computer Security Laboratory Dept. of Computer Science University of California at Davis...