Chapter 2, "Overflowing Buffers on the Stack," page 28

Welp, it looks like it's the end of the line for my stock Ubuntu kernel -- it's clear that Ubuntu 8.10 is using ASLR (Address Space Layout Randomization), as described later in Chapter 14, on page 396.

Now, I did mess with find_start.c a little to match up where the stack actually starts with what's reported in /proc/<pid>/maps. Here's that -- and this looks like it might be marginally useful in actual exploitation:

#include 
// find_start.c
unsigned int find_start(void)
{
  __asm__("movl %esp, %eax");
}

int main()
{
 printf("Found start: 0x%x\n",find_start());
 printf("*********************************\n");
 char path[80];
 sprintf(path, "/proc/%d/maps",getpid());
 printf("Snarfing %s\n",path);
 char *cmd[3];
 cmd[0] = "/bin/cat";
 cmd[1] = path;
 cmd[2] = 0x0;
 execv(cmd[0],cmd);
}

Excuse my ghetto C, but this allows me to see output like:

todb@mazikeen:~/dev/sc$ ./find_start 
Found start: 0xbfb17e7c
*********************************
Snarfing /proc/4264/maps
[... memory map here...]
bfb05000-bfb1a000 rw-p bffeb000 00:00 0          [stack]
todb@mazikeen:~/dev/sc$

Running this a few times elicits different results for both the found start value, and the start and end of the stack. Too bad I'm way too stupid to work through how to fix this up with my usual running kernel -- I will have to procure or compile a new kernel without ASLR to make any more headway with this example exploit. I guess I'll get back to it later.

One great pointer here though is that this author states he's "running on Debian 3.1r4," so it would probably be a good idea to create a VM with that distro for the rest of the exercises. It'll still be interesting to note where certain attacks succeed on this (multiyear out of date) build versus the new Linux hotness. this link (specifically the gnome.org version) may work for our purposes.