- 程序有所改变。发帖如还有问题请报告
- 【征集】西西河的经济学，及清流措施，需要主动参与者，『稷下学宫』新认证方式，24年网站打算和努力目标
主题：一篇讲memory overflow导致被攻击的文章 -- yueyu
这篇paper很有趣，也很有用。
扪心自问，我们几个人真正考虑代码的安全性了？有几个人的代码经得起安全专家的推敲的？
我记得以前看关于secure codes方面的paper，一边看，一边流冷汗。我觉得自己已经够nerd的了，但山外有山
http://insecure.org/sploits/non-executable.stack.problems.html
哪位同学有空，可以翻译出来以饷同好
http://insecure.org/sploits/non-executable.stack.problems.html
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]>
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 帖 引用 (帖内工具实现)
还有就是可以先去wikipedia上先看一下大致的概念，然后仔细推敲代码
http://www.neworder.box.sk/newsread.php?newsid=12476
Wikipedia上的简介
http://en.wikipedia.org/wiki/Buffer_overflow
比如MEMCPY,STRCPY,PRINTF,SCANF之类。
关键之一是对程序员“再教育”，比如去读Writing Secure Code，但是现在还有多少程序员既懂高级语言，又至少精通一个指令体系的汇编（比如X86,mips,或者ARM）?没有汇编的基础是不可能掌握“内存溢出”攻击的精髓的。
我不用不安全的函数，那我调用的library里面有没有用不安全的函数？被我调用的library调用的library有没有用不安全的函数？
至于scanf，printf，memcpy，strcpy，没有他们，很多人程序都写不下去了（我经常这样，类似提笔忘字）。有些程序本来只是小众用途，根本不用考虑安全问题。可是谁也说不准是否将来会有人直接拿了你的程序去distribute。
就算不是用c，用其他解释语言，也有可能通过解释器调用的library来进行攻击。
网上无数篇文章在讲，计算机－特别是软件这个行当门槛太低。
的确，实际工作中，你发现一个不用懂什么计算机系统结构的人也能写出很复杂漂亮的软件（至少表面上）。
可是，真正有多少人了解一个程序run起来，背后有多少components在支持他呢。这里的components，我说的是包括软件到硬件一整套。如果你一直都在为一套你不了解的系统工作，你的工作有什么乐趣呢？
或许我的想法还是太nerd。我觉得真正成长期从事软件行业的人，必定是要对整个计算机系统都充分了解，门槛一点都不低。否则长久下去，必然厌倦，也没办法走到更高的境界了（想到了葛优对境界的解释了）。
class a
{
public:
a(void)
{...
}
f1(void)
{...
}
f2(char *pBuf)
{
strcpy(&c1[0], pBuf);
}
private:
char c1[12];
}
ff2(char *pC1)
{
a *p_a0 = new a();
a *p_a1 = new a();
p_a0->f2(pC1);
p_a1->f1();
...
delete p_a0;
delete p_a1;
}
p_a0->f2(pC1);
当strcpy发生的时候，下面可不知道执行到哪儿去了
而f2(char *pBuf)这个pBuf很可能是外面谁给输入的
p_a1->f1();
吃饭先
越看越觉得清爽。
表面看起来简单，但是揭示的问题很深刻。
简直不让人吃饭了。
memcpy是安全的吧？
或者太守兄指的是memcpy源和目的地址overlap的问题，建议用memmove?不过那个不是缓存区溢出吧？
我无法预测这题能让多少人阵亡。。。