2

Unfortunately, I dont seem to understand one minor concept in the "Art of Exploitation" book, concerning heap overflow: a new root shell is being added to the passwd file. From page 168:

However, the nature of this particular heap overflow exploit won’t allow that exact line to be written to /etc/passwd, because the string must end with /etc/passwd. However, if that filename is merely appended to the end of the entry, the passwd file entry would be incorrect. This can be compensated for with the clever use of a symbolic file link, so the entry can both end with /etc/passwd and still be a valid line in the password file. Here’s how it works:

reader@hacking:~/booksrc $ mkdir /tmp/etc
reader@hacking:~/booksrc $ ln -s /bin/bash /tmp/etc/passwd
reader@hacking:~/booksrc $ ls -l /tmp/etc/passwd
lrwxrwxrwx 19 2007-09-09 16:25 /tmp/etc/passwd -> /bin/bash

Now /tmp/etc/passwd points to the login shell /bin/bash. This means that a valid login shell for the password file is also /tmp/etc/passwd, making the following a valid password file line:

myroot:XXq2wKiyI43A2:0:0:me:/root:/tmp/etc/passwd

The values of this line just need to be slightly modified so that the portion before /etc/passwd is exactly 104 bytes long:

  1. I understand the part when the author states that /tmp/etc/passwd can be used to link to /bin/bash, but I don't understand how this really works (there is no explanation of mkdir, ln -s etc)

  2. Also, this is probably very simple, but why does the author state that: "the values of this line just need to be slightly modified so that the portion before /etc/passwd is exactly 104 bytes long"? Why was /tmp omitted in the previous line (i.e. why isn't it stated: "the portion before /tmp/etc/passwd is exactly 104 bytes long" ? On the next page, the new root account is written to /etc/passwd, but why not to /tmp/etc/passwd? I've checked, and there are 2 different etc folders on the system; why is this the case?

1 Answers1

2

There is an explanation in the actual book (maybe this 'leaksource' site isn't reliable ;-).

  1. You type commands: mkdir /tmp/etc; ln -s /bin/bash /tmp/etc/passwd
  2. (A)The heap contains two buffers and 104 bytes is the maximum distance between the first buffer and the datafile allocation buffer. (B)/tmp was not omitted, /etc/passwd will be appended to the end of the string shown in bold. The last part of that string shown in bold reads :/root:/tmp. So when completed with the above it will write …:/root:/tmp/etc/passwd to the first buffer and /etc/passwd will overrun into the buffer datafile @ 0x804a070 as shown on the next page. (C & D) It won’t write to /tmp/etc/passwd because that is only a symbolic link to /bin/bash.

The overall idea is to append the /etc/passwd file that has a User ID of 0 so you can be given root privileges. The way this exploit is carried out: “the overflow needing to be the destination file “/etc/passwd” doesn’t allow for us to append the file using myroot:XXq2wKiyI43A2:0:0:me:/root:/bin/bash (if we used this as part of the overflow it would write to /bin/bash). You are creating /tmp/etc/ for two reasons:

  1. to have an overflow into the datafile allocation buffer of /etc/passwd (i.e. the file you want to write to).
  2. to have a valid login shell for your entry into password file WITHOUT ruining the target system & actually messing up your whole password file.

A blog post that might help you out. If you aren't familiar with the linux commands like mkdir and ln, let me recommend CodeAcademy's Command Line Course or a command line tutorial out of many you could google.

Gilles 'SO- stop being evil'
  • 50,912
  • 13
  • 120
  • 179
eTo-san
  • 331
  • 1
  • 6
  • Thank you for your reply. Perhaps I was a bit unclear in my initial question, and I've now updated it. Also, you've stated that: "It won’t write to “/tmp/etc/passwd” because that is only a symbolic link to /etc/passwd." I am quite sure that the former (/tmp/etc/passwd) is a symbolic link to /bin/bash. I think that /tmp was necessary for the creation of this link, but I don't know why or how. – Ruslan Mushkaev May 29 '16 at 19:12
  • @RuslanMushkaev, you are correct. Thanks! I changed it to reflect the correct symbolic link. Hopefully, my additional explanation elucidates that you are doing two things at once why using /tmp as a symbolic link as input into the two key buffers. – eTo-san May 29 '16 at 21:12