DOC PREVIEW
Stanford CS 155 - Study Notes

This preview shows page 1 out of 2 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 2 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 2 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

CS155: Computer Security Spring 2002Project #3Due: Wednesday, June 5th, 2002.In this project, you will perform a security audit of another group’s Josh. You will produce a shortaudit document analyzing the other group’s decisions, algorithms, and code in implementing Josh.Additionally, if you find exploitable vulnerabilities of any sort within the Josh code you are auditing,you are encouraged to implement exploits for these vulnerabilities and include them with your audit.The AuditIn a file called AUDIT, you are to produce a security audit document. You should comment on theorganization of the Josh you are auditing.For each of the tasks involved in Josh, you should document and analyze the choices which thegroup made in writing Josh, both the algorithms and implementation used.As a reminder, the Josh tasks are josh exec, josh access, the editor, journaling, and the extra credit;refer to the Project Two handout.Wherever you see a potential security vulnerability, you should be sure to comment on it and itsimplications.You need not write too much; 1500 words should be sufficient.Exploit CodeIf you can find a security vulnerability in the Josh you are auditing, and are able to exploit it, youshould write up an automated exploit for the vulnerability and include it with your submission.We have reproduced the section “What Constitutes a Security Vulnerability” from Project Two atthe bottom of this document.As an attacker, you have a great deal of latitude in attacking Josh. You may, for example, set/etc/josh access and /etc/josh exec to any reasonable contents; you may create users and set their~/.josh_* files; you may install files where you wish. (The Makefile is the right place for this.)To script interaction with Josh, you may find expect handy. Refer to its manpage for moreinformation.DeliverablesAs in the first programming assignment, you will use the online Leland submit script,/usr/class/cs155/bin/submit. This is bfp2.The directory which you submit must contain the audit document, with filename AUDIT, and allexploit code. If you include executable code, you should also provide a Makefile for compiling it.Along with your audit and exploits, you must include file called ID which contains, on a single linefor each person in your team, the following: your SUID number; your Leland username; and your1name, in the format last name, comma, first name. An example:$ cat ./ID3133757 binky Clown, Binky The$If you work alone, ID should have exactly one line. If you work with a partner, ID should haveexactly two lines.Do not include any identifying information in any file except ID.You will also want to include a README file with details of your design, comments about yourexperiences, or suggestions for improving the assignment.How You Will Be GradedAs always, all testing will take place in a closedbox environment, with Josh installed setuid root as/usr/local/sbin/josh .You will be graded on the completeness and insightfulness of your security audit document.In addition, any exploits you find and automate will raise your grade. Your comments will beprovided to the group whose code you audit. (This, again, is why it is important that you notidentify yourselves in any file other than ID.)What Constitutes a Security Vulnerability(This section duplicated from Project Two.)In an application like Josh, a security vulnerability is anything that allows a player in the system toobtain additional privileges. We list some possibilities below; this is not meant to be an exhaustivelist.Obviously, if a buffer overflow in Josh allows untrusted user Alice to obtain a root shell, that’s avulnerability.If Alice can obtain read or write access to a file, or execute access to a program beyond what isgranted to her by root, that’s a vulnerability.If Alice can obtain access to more of Bob’s files than she should, that’s a vulnerability.If Bob can configure his files so that, as Alice runs Josh, she is tricked into giving Bob some subsetof her privileges, that’s a vulnerability.If the system administrator, in going over the Josh journal files, is misled about the activities thattook place on the system, or is tricked into giving up more privileges, that’s a vulnerability.Denial-of-service attacks may rise to the level of security vulnerabilities if they are serious: forexample, if Bob can use Josh to disable Alice’s login. (Attacks prevented by effective use of ulimitsobviously don’t count.)In demonstrating an exploit, you may assume any reasonable configuration for the various filesJosh uses to determine access; but, obviously, an exploit that derives from misconfiguration is notan exploit against


View Full Document

Stanford CS 155 - Study Notes

Documents in this Course
Lecture 5

Lecture 5

64 pages

Phishing

Phishing

31 pages

Load more
Download Study Notes
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Study Notes and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Study Notes 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?