淘客熙熙

主题:一篇讲memory overflow导致被攻击的文章 -- yueyu

共:💬64 🌺34
分页树展主题 · 全看首页 上页
/ 5
下页 末页
  • 家园 一篇讲memory overflow导致被攻击的文章

    这篇paper很有趣,也很有用。

    扪心自问,我们几个人真正考虑代码的安全性了?有几个人的代码经得起安全专家的推敲的?

    我记得以前看关于secure codes方面的paper,一边看,一边流冷汗。我觉得自己已经够nerd的了,但山外有山

    http://insecure.org/sploits/non-executable.stack.problems.html

    哪位同学有空,可以翻译出来以饷同好

    http://insecure.org/sploits/non-executable.stack.problems.html

    Defeating Solar Designer's Non-executable Stack Patch

    Summary

    Description: A very interesting paper on defeating non-executable stack patches. It goes through the steps needed to exploit the XServer <LONGDISPLAY> hole in Linux even with a non-execute patch.

    Author: Rafal Wojtczuk <[email protected]>

    Compromise: root (local)

    Vulnerable Systems: This just shows (as Solar Designer is well aware) that in some cases the non-executable stack patch can be subverted via sneaky techniques.

    Date: 30 January 1998

    Notes: Solar Designer's respons is in the addendum.

    Details

    Date: Fri, 30 Jan 1998 18:09:35 +0100

    From: Rafal Wojtczuk <[email protected]>

    To: [email protected]

    Subject: Defeating Solar Designer non-executable stack patch

    -=[ Defeating Solar Designer's Non-executable Stack Patch ]=-

    Text and souce code written by Rafal Wojtczuk ( [email protected] )

    Section I. Preface

    The patch mentioned in the title has been with us for some time. No doubt it

    stops attackers from using hackish scripts; it is even included in

    just-released Phrack 52 as a mean to harden your Linux kernel. However, it

    seems to me there exist at least two generic ways to bypass this patch fairly

    easily ( I mean its part that deals with executable stack ). I will explain

    the details around section V.

    Before continuing, I suggest to refresh in your memory excellent

    Designer's article about return-into-libc exploits. You can find it at

    http://www.geek-girl.com/bugtraq/1997_3/0281.html

    "I recommend that you read the entire message even if you aren't

    running Linux since a lot of the things described here are

    applicable to other systems as well."

    from the afore-mentioned Solar Designer's article

    更多的,大家有兴趣,我们再仔细讨论。

    iphone就是这么被破解滴


    本帖一共被 1 帖 引用 (帖内工具实现)
    • 家园 一点更正+八卦

      不能说iPhone是这么被破解的。

      这篇文章是很经典的return to libc 攻击。其实严格意义上说他不是一种新的BufferOverflow,而是将如何exploit BO。

      Rafal是第一个提出这个思路的人,他因此在Security界享有广泛的声誉。类似的,他还发现了在MacOS下如何绕过NX保护的方法。

      此公沉默寡言,桥牌水平很高。

      • 家园 link

        old thread

        • link
          家园 请问您要干啥?

          怎么把老文章翻出来了?

          • 家园

            1.那个线谈到了OS安全(俺对那个安全OS也不是。。。),谈到了溢出攻击(BY 老成都)。

            2.引用该线的另一个目的是你在其中列举的“source code auditing都已经是一个产业”。是否有些人也可以利用这种工具找找现有开源项目的漏洞?

            • 家园 那个是很老的口水帖了

              是啊。这些公司都是发现了很多的开源漏洞,不过都是直接报给他们了,不会放出来的。而且这些软件都异常昂贵,而且更适合开发人员使用。

              现在找漏洞的方法不是光靠看代码的。一般都是fuzzing。

              • 家园 口水里面还是有一定的“蛋白质”。

                俺反对为口水而口水。

                起码你在那个线上提供了若干个厂商的名头,在搜索引擎时代,这就是口水里面的“蛋白质”。

                很多这些“专业工具”确实不便宜,但这些厂商能在这个地方找到饭碗,还是有他们存在的道理的。

                楼下的漏洞争论俺看有被口水淹没的可能。unix vs windows或者说 开源vs“封闭”是IT论坛的“月经"线,现在看离更年期闭经还早,时不时就来上一次。

      • 家园 原理一样而已

        iphone当然不是“这么”被破的

        iphone是当初有人猜测MacOS用了有问题的libtiff,进而发现的确这个libtiff有问题。问题就是data overflow,然后就把exectuable stack的地址给覆盖了。

        至于真正破解iphone的过程,当然不是文章中写的“这么”破解的。

        • 家园 这么说没问题

          jailbreak的那个exploit写的挺不错的,思路挺巧的。

          说起来还是Apple在security方面重视程度不够,这方面微软可要领先一步,Vista早就已经能够把库函数和关键系统数据的地址随机化(ASLR)了。无他,被打怕了。

          不过Apple最近也已经加了ASLR。

    • 家园 标准答案之一是不用那些不安全的C函数。

      比如MEMCPY,STRCPY,PRINTF,SCANF之类。

      关键之一是对程序员“再教育”,比如去读Writing Secure Code,但是现在还有多少程序员既懂高级语言,又至少精通一个指令体系的汇编(比如X86,mips,或者ARM)?没有汇编的基础是不可能掌握“内存溢出”攻击的精髓的。

      • 家园 问个外行话,

        既然知道这几个函数会导致溢出,为什么不升级libc库,给这些函数加上地址检查,这样不就万事大吉了么.

        • 家园 问题是。。。

          1.这些函数本身是无法自身检查的(函数调用参数太少),所以只能是调用者在调用之前检查。

          2.大量已经存在的程序除非重新修改,编译,链接,分发,否则“漏洞”还是在那里。

          • 家园 那能不能升级gcc编译器哪

            那能不能升级gcc编译器哪,让编译器在碰到这些函数的时候先预处理一下,这样只要从新编译,连接一下就可以了,这样一般程序员的习惯也不用调整了.安全专家们只要把发现的问题定期发布,更新一下编译器就行了.

            • 家园 可以设想一个case

              strcpy

              参数是char*

              ,原来是靠\0来判断结束的,而程序员也习惯了如此。编译器也不像strncpy一样有长度信息来判断copy多少个字节,所以也没办法做检测。一个可能的方案是再套一层VM,重新定义char*,让他默认编译进去一个length。这就是Java作的事情。

              但是问题又来了,如果这个VM有安全漏洞呢?因为VM的实现,也只能是C。

              当然,可以最底层的OS里面,char*就编译一个length进去,但连kernel都要重写了,工作量巨大。

            • 家园 信息不足,编译器也帮不上忙

              唯一能做的,就是碰到类似不安全函数调用的时候,给个warning,让程序员注意了。

分页树展主题 · 全看首页 上页
/ 5
下页 末页


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河