matt bishop computer security laboratory dept. of computer science university of california at davis...
Post on 21-Dec-2015
219 views
TRANSCRIPT
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
Matt BishopComputer Security LaboratoryDept. of Computer ScienceUniversity of California at Davis
Shhhh...
Three can keep a secret …
… if two of them are dead.
VP/07241998 Slide # 3
Matt BishopComputer Security LaboratoryDept. of Computer ScienceUniversity of California at Davis
Outline
• Review project goals• Status of vulnerabilities database• Status of analysis technique• A few other things …
VP/07241998 Slide # 4
Matt BishopComputer Security LaboratoryDept. of Computer ScienceUniversity of California at Davis
Project Goals
• To present techniques for finding these vulnerabilities
• To present techniques to inhibit or eliminate exploitation of those vulnerabilities
VP/07241998 Slide # 5
Matt BishopComputer Security LaboratoryDept. of Computer ScienceUniversity of California at Davis
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
Matt BishopComputer Security LaboratoryDept. of Computer ScienceUniversity of California at Davis
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
Matt BishopComputer Security LaboratoryDept. of Computer ScienceUniversity of California at Davis
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
Matt BishopComputer Security LaboratoryDept. of Computer ScienceUniversity of California at Davis
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
Matt BishopComputer Security LaboratoryDept. of Computer ScienceUniversity of California at Davis
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
Matt BishopComputer Security LaboratoryDept. of Computer ScienceUniversity of California at Davis
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
Matt BishopComputer Security LaboratoryDept. of Computer ScienceUniversity of California at Davis
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
Matt BishopComputer Security LaboratoryDept. of Computer ScienceUniversity of California at Davis
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
Matt BishopComputer Security LaboratoryDept. of Computer ScienceUniversity of California at Davis
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
Matt BishopComputer Security LaboratoryDept. of Computer ScienceUniversity of California at Davis
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
Matt BishopComputer Security LaboratoryDept. of Computer ScienceUniversity of California at Davis
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
Matt BishopComputer Security LaboratoryDept. of Computer ScienceUniversity of California at Davis
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
Matt BishopComputer Security LaboratoryDept. of Computer ScienceUniversity of California at Davis
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
Matt BishopComputer Security LaboratoryDept. of Computer ScienceUniversity of California at Davis
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
Matt BishopComputer Security LaboratoryDept. of Computer ScienceUniversity of California at Davis
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
Matt BishopComputer Security LaboratoryDept. of Computer ScienceUniversity of California at Davis
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
Matt BishopComputer Security LaboratoryDept. of Computer ScienceUniversity of California at Davis
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
Matt BishopComputer Security LaboratoryDept. of Computer ScienceUniversity of California at Davis
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
Matt BishopComputer Security LaboratoryDept. of Computer ScienceUniversity of California at Davis
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
Matt BishopComputer Security LaboratoryDept. of Computer ScienceUniversity of California at Davis
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
Matt BishopComputer Security LaboratoryDept. of Computer ScienceUniversity of California at Davis
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
Matt BishopComputer Security LaboratoryDept. of Computer ScienceUniversity of California at Davis
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
Matt BishopComputer Security LaboratoryDept. of Computer ScienceUniversity of California at Davis
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
Matt BishopComputer Security LaboratoryDept. of Computer ScienceUniversity of California at Davis
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
Matt BishopComputer Security LaboratoryDept. of Computer ScienceUniversity of California at Davis
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
Matt BishopComputer Security LaboratoryDept. of Computer ScienceUniversity of California at Davis
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