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
big_int mod_exp(big_int b, big_int e, big_int m)
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);
The initial handout is available in postscript
Homework / Projects
- 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
- 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
- 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
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.
Scan through the Orange book (DOD 5200.28-STD, 85)
(earlier version (CSC-STD-00l-83) also available)
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.
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?
Thompson's 1984 Turing Award Lecture, Reflections on Trusting Trust. A true classic. (May 3)
The Protection of Information in Computer Systems (Q&A on May 10)
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)
The Design and Implementation of Tripwire (Q&A on May 17)
Building Diverse Computer Systems (Q&A on May 19)
Security Problems in the TCP/IP Protocol Suite
(Q&A on May 24)
Useability of Security
(Q&A on May 26)
Security Releated News / Current Events
Here are some recent news items related to security
Sketch of topics covered in class thus far:
- ethics. do not break in without invitation.
- security properties: confidentiality, data integrity, message integrity, message non-repudiation
- threat model / assessment
- assets. replacement value. value to attackers.
- attacker. population size. skill levels.
- economics of security; security as insurance
- security policy: logical security. physical security. personnel
security. disaster recovery.
- orange book / classical military security. (read orange book.)
A-D classifications. MAC/DAC. bell-lapadula. least privilege.
- known attacks
- buffer overflows
- tenex password. covert channels.
- setuid shell scripts
- /tmp files
- differential timing / power analysis
- differential fault analysis
- are there general principles to avoid designing systems with
similar security holes?
- ACID transactions; modularity
- Reflections on Trusting Trust
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 |
pgp key svr |
email@example.com, last updated Fri Jun 4 15:07:14 PDT 1999.email bsy