CSE 127: Lecture 7


The topics covered in this lecture are assignment 1, the basic gdb commands, the compiling and linking process, buffer overflows and security problems, and the IFS attack.

Assignment 1

Download the assn1 tar file. In it you'll find a README.txt file which specifies what you must hand in for this assignment.

Notes on assignment 1:

gdb commands

In order for gdb to be able to provide symbolic debugging (using names of functions and variables from C rather than using machine addresses), you must compile your C code with the -g flag, i.e.,
$ cc -g -c foo.c
$ cc -g -c bar.c
$ cc -g -o a.out foo.o bar.o

List of gdb commands: break, run, help, print, x/i, x/x.

x/i and x/x are low-level commands to examine memory. The /i means ``interpret the data as an assembly instruction''. The /x means ``interpret the data as a hexadecimal value''.

Compiling and Linking

Compilers generate .o files which contains machine code with placeholders for external references, and a symbol table to allow the linker to patch up these placeholders.

The general form for an executable (a.out) or a .o file is a header plus sections:
header
code section
initialized data section
symbol table section
other sections...

Imagine we have two source files:
foo.cbar.c
int bar(int);
void foo() {
    int x;
    ...
    x = bar(3);
    ...
}
int bar(int j) {
    return j + 1;
}

When you run

$cc -c foo.c
...you get the file foo.o, which is a relocatable object. It has a reference to the function int bar(int), but it does not actually know where to jump to get to that function. The external reference has not been resolved. This illustrates the difference between declaration and definition in programming languages (i.e. in the file foo.c, the function bar() has been declared but not defined).

The linker -- what is run when you generate an executable -- resolves external references and assign addresses to all code and data. An example of this is:

$cc -o a.out foo.o bar.o

When the kernel loads the executable, it maps the program into its own virtual address space like this (just an example):
memory addressitem
0xF0000000 (high mem)kernel
0xE0000000program stack (growing down)
......
0x00100000initialized data
0x00000000 (low mem)program code

The memory allocated to code is static in most operating systems, meaning it can't be modified. This is useful because multiple processes running the same program can share these ``text'' pages, resulting in lower physical memory utilization.

Buffer overflows and security problems

What types of security properties (e.g. integrity, privacy) can be violated by a buffer overflow attack? The buffer overflow itself may result in a minor compromise, but it may lead to other attacks. For example, on most systems user accounts other than `root' are not privileged enough to cause much damage to the whole system. But there are other attacks that may be executed as a user which can be used to get root access. These are called `stepping stone' attacks, because the first attack (buffer overflow) is used to gain access to a non-privileged user's account, and from there another attack may gain access to the root user, from where real damage may be done. Because of this, a buffer overflow may eventually lead to violations of any of the security properties we have discussed.

IFS attack

I will not be describing the IFS attack in detail on the class web page. Ask the TAs or your classmates for an explanation.

This attack, which gives the attacker root privileges, is one which requires the attacker to already be able to run processes on the machine. Such an attack might be mounted by a remote, network-based attacker after she/he uses a buffer overflow attack to gain normal user level access to a machine.


[ search CSE | CSE | bsy's home page | links | webster | MRQE | google | yahoo | citeseer | certserver ]
picture of bsy

bsy+cse127w02@cs.ucsd.edu, last updated Mon Mar 25 15:22:10 PST 2002. Copyright 2002 Bennet Yee.
email bsy.


Don't make me hand over my privacy keys!