CSE 227 Home Page

This is the class home page for CSE 227, Computer Security.

The take-home final is now available [also PDF]. It is due Tuesday, June 8th, 6pm (at the end of the scheduled final exam period).

Final Exam Clarifications:

Question 7: Give the necessary conditions....
Question 8: The code for mod_exp contains a minor bug. It should read:

big_int mod_exp(big_int b, big_int e, big_int m)
	int i;
	big_int y;
	big_int x = b;	/* OMITTED EARLIER */

	for (i = 0, y = 1; i < MAXBITS && e != 0; i++, x = mod_mult(x,x,m), e = e / 2)
		if ((e % 2) == 1) y = mod_mult(y,x,m);
	return y;

The initial handout is available in postscript [PDF].

Homework / Projects

  1. due 4/9. Write a threat model/assessment for your home, lab, or work. Give assets to be protected, attacks and skills involved, and estimate costs of the attacks, etc, as we discussed in class. To alleviate confidentiality concerns, you don't have to exhaustively list your assets -- you may substitute parts with assets with similar security requirements. Turn it in by email.
  2. due 4/19 before class. Attack the given program. Make sure that it works on Solaris machines. In your write-up, describe what you had to do, why it was needed for the attack to succeed, and describe any tools that you had to create to mount the attack. Also give detailed instructions on how to use your attack tools so that I can verify that things work in my own environment. Your tools may depend on the test program's output.

    You should turn in the write-up along with all of your source code. Do not include the original assn2.c source code, any executables or binary data. Turn in the assignment by email.

  3. due 6/4. Identify security weaknesses and attack this RPC system (orig). (You may attack either the original version or the updated one; identify which in your write-up.) The client/server code provided shows how this simple RPC system is used. You must modify the client so that the server -- code unchanged -- can be made to print "Hello world" to its standard output. Your attack code must work in the Solaris environment. To run the client side, you'll need the net_redir program as well.

    A list of preliminary bugs (accidentally released) is here. If you got the earlier version of the tar file, you should modify the Makefile to include -lsocket.

    Your write-up should include an exhaustive list of the security vulnerabilities and design flaws, and describe in detail how you mounted your attack. Additionally, you should provide a new version of the RPC system which fixes all the security bugs that you identified.

    Your Makefile (for Solaris) should include the line

    as well as the -lsocket -lnsl for the final linking step. Also, change the uses of mcopy in rpc.c to memcpy.

    For those of you who are confused about the use of net_redir, you compile it by:

    cc -o net_redir net_redir.c -lsocket -lnsl
    (The -lsocket -lnsl is needed only on Solaris.) And you run the server as:
    % ./server -p 6789 -v
    in one window on a Solaris machine, say named beowulf, and then in another window -- on any machine, as long as you have compiled the client with the right byte-ordering conditional compilation directives -- you run the client as:
    % ./net_redir -s 6789@beowulf -d 3 -- ./client -v
    The number 6789 in both the server and the client command lines is the TCP port number at which the service is located. (The -s flag allows you to use service names found in /etc/services as well.) The number that you use doesn't have to be 6789 -- as a matter of fact, since the server will fail to acquire that port number if somebody is already using it, you should probably chose your own. The only restriction other than its being unused is that it must also be above 1000, which on Unix systems are reserved for use by system services.

    To check whether your Solaris machine is configured so that the stack segment is not executable, run /home/bsy/exposed/stack_test.sun4. If it dumps core, then it doesn't allow execution from the stack; if it outputs a message, then you're okay. This is executable only from CSE machines and directly tries executing from the stack. If you're doing initial implementation elsewhere, you should scan through /etc/system for set noexec_user_stack = 1, which is the configuration entry that controls this.

Reading Assignments

  1. Scan through the Orange book (DOD 5200.28-STD, 85) (earlier version (CSC-STD-00l-83) also available) and a summary of the differences between it and DoD Standard 5200.28. The Orange Book is the classical specification of multi-level security, and deals with trusted computing bases, trusted paths, data labelling, etc. Aka TCSEC.
  2. For your own edification, you may want to want to peruse the MIT guide to lock-picking (also in PDF) which explains how cylinder locks are designed. Is it possible to design a lock that uses one key to lock and another key to unlock?
  3. Thompson's 1984 Turing Award Lecture, Reflections on Trusting Trust. A true classic. (May 3)
  4. The Protection of Information in Computer Systems (Q&A on May 10)
  5. Software Fault Isolation paper. (Q&A on May 12) (check out an hopefully fixed version with a better page 7 / figure 4, at least when previewing with gv/ghostview; you may also want to look at page 7 by itself)
  6. The Design and Implementation of Tripwire (Q&A on May 17) (PDF)
  7. Building Diverse Computer Systems (Q&A on May 19) (PDF)
  8. Security Problems in the TCP/IP Protocol Suite (Q&A on May 24) (PDF)
  9. Useability of Security (Q&A on May 26) (PDF)

Security Releated News / Current Events

Here are some recent news items related to security
  • NASA plagued by security problems
  • infosec: UK MI-6 secret agents list disclosed
  • infosecurity asia, a trade show in Singapore, has a contest to break into ``secure'' web servers, with monetary prizes.
  • Microsoft to build Unix email client due to Army's message-security concerns
  • Hackers attack U.S. government web sites in protest of bombing of Chinese embassy
  • DOE orders all computer work halted at three nuclear weapons labs due to possible computer security lapses Note the quote
    But John C. Browne, lab director at Los Alamos, cautioned that the labs cannot allow security to become so stringent that it prevents them from accomplishing their objectives. "We have to look at threats to information security from a risk-benefit standpoint and put in place additional procedures that make sense," he said. "We can't raise the bar so high we can't get any work done. That affects national security too."
  • article on SSN privacy at CNN
  • Deja news privacy snafu
  • Lecture Topics

    Sketch of topics covered in class thus far:

    Bennet maintains a list of Web resources relating to computer security, ranging from cryptography resources, system security testing tools, to word compilations useful in eliminating easy-to-guess passwords. Some/most of these links are somewhat old.

    [ search CSE | CSE home | bsy' home page | webster i/f | yahoo | hotbot | lycos | altavista | pgp key svr | spam | commerce ]
    picture of bsy

    bsy+cse227@cs.ucsd.edu, last updated Fri Jun 4 15:07:14 PDT 1999.

    email bsy

    Don't make me hand over my privacy keys!