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
|
--------------------------------------------------------------------------
TESO Internal Paper
06/25/2001
How to exploit Telnet Daemon on Solaris Sparc
--------------------------------------------------------------------------
This Paper describes how i am going to try to exploit the telnet daemon
on Solaris Sparc maschines. The basic idea in exploiting was to overflow
the [netobuf] until we can overwrite the pointer [netibuf] which points
into heapspace and is meant for the incoming data. The idea was to fill
the heap before with environment variables so that 0x00FFFE08 points
into valid heapspace. Further was the idea to continue reading data
again from the socket and so overwriting the malloc structure in memory.
A carefully modification will allow us to overwrite an abritary memory
adress (GOT, PLT, RETADDR) with our returnadress so allowing us to
execute our own shellcode...
So far the theory, now the hard reality...
All info following is valid for the Solaris Sparc 2.6 in.telnetd binary
i had access to.
the memorylayout is like this:
00000 netobuf[1024]
...
+03063 ncc
...
+03091 *netibuf
and this memory layout is exactly what causes the problem. If we start
sending a bunch of IAC AYT request, we will overwrite ncc with a very
huge positive integer. This causes our telrcv function to loop again
and again. The telrcv function will only stop its loop if ncc becomes
negative or the ptyoutputbuffer is full. This will happen soon, but
after flushing it, the telrcv loop will continue. The major problem is
that [netibuf] is not big enough to hit the pointer, send an AO and
then hit ncc again to make it negative, because this is the only way
we are able to come to the next read...
The solution seems easy, but because i have no solaris shell i could
test it yet:
We sent a lot of envvars before trying to overwrite the vars, didnt we?
Because netibuf is malloc before the envvars, it is right infront of
them in heapspace. So our telrcv will very soon hit into one of our
envvars (the first one). We can store a IAC AO and lotsa 0xff 0xfb 0x80+
there. (most probably we need more envvars). we need enough of them
to hit ncc again. this time it will make it negative and so the loop
ends and our new [netibuf] (which points somewhere in the middle of the
heap) The next read should give us enough power to read in any stuff to
corrupt the malloced envvars and so overwrite either plt, got or retloc.
the retaddr into our shellcode is easy to get, cause we know exactly the
offset where our netibuf is read to. (dont forget that 0xff will cause
problems... (so keep them out of shellcode)).
This all must of course be tested and implemented... i am waiting for
a solaris sparc root account to do it...
lorian
|
