存档

作者存档

Intersec内存系列文章–第5部分:调试工具

2014年3月17日 没有评论

原文:http://techtalk.intersec.com/2013/12/memory-part-5-debugging-tools/

翻译:童进

引言

我们又回来了!前面我们用了4篇文章介绍什么是内存、如何去处理它,那么对于内存又会遇到怎样的问题呢。即使是最优秀的开发人员也会有bug。一个被普遍接受的估算是每千行代码可能有几十个bug ,这无疑是相当多的。因此,即使完全掌握了我们文章所述的内容,你仍然可能会遇到一些内存相关的bug。

内存相关的bug可能特别难发现和修复。我们以下面的程序为例:

mem_debug_program

这个程序的原意是将一个message作为参数打印“ hello <message>!”(默认的message是“world”)。

该程序的行为是完全不确定的,它有bug但不一定会crash。build_message函数返回一个指向分配在栈帧上的内存的指针。由栈的工作原理可知这块内存很容易被随后调用的函数覆盖,在这里很可能是fputs。因此,如果fputs内部使用足够多的栈内存从而覆盖了message,那么输出将不正确,甚至造成程序crash,而在其它情况下,程序将打印预期的消息。此外,因为使用了不安全的sprintf函数(它对写入的字节数没有限制),该程序可能会溢出。

因此,程序的行为依赖于命令行中输入的message大小、MAX_LINE_SIZE的取值以及fputs的实现[……]

阅读全文

分类: *nix安全 标签: , ,

Intersec内存系列文章–第4部分:Intersec自定义分配器

2014年3月17日 没有评论

原文:http://techtalk.intersec.com/2013/10/memory-part-4-intersecs-custom-allocators/

翻译:童进

malloc()并不是一个适用于所有场合的分配器

malloc()因其通用性使用起来非常方便。它不会对分配和释放内存的情境做任何假设。内存的申请/释放可以是连续的,也可以在整个任务执行中分开,既能发生在同一线程中,也可以在不同线程中。分配器的通用性使得每次分配互不相同,这意味着不同生命周期的内存会共享相同的内存池。

因此malloc()的实现很复杂。由于内存可以被多个线程共享,所以内存池也必须共享,并且分配过程中需要加锁。同时现在硬件支持越来越多的物理线程,因此每次内存分配时的加锁会对性能造成极大影响。也正是因为如此,目前的malloc()实现拥有线程本地缓存,只有当缓存过小或过大时才会锁内存池。(译者注:过小时,需要向内存池请求资源,过大时会被垃圾回收机制回收到内存池)它的副作用就是,一些内存在线程本地缓存中,其他线程无法轻易访问。

由于内存块可以在不同的地方(线程本地缓存,全局内存池,或者只是简单地分配给进程),堆会变得碎片化。这将难以把未使用的内存释放回内核,并极有可能导致两次连续的分配,却返回相距甚远的内存,导致对堆的随机访问。在上一篇文章中我们看到,随机访问绝不是内存访问的最佳方案。(译者注:无法利用内存的局部性)

因此,拥有一个能预测其行为的专用分配器在某些情况下确实是必须的。在Inters[……]

阅读全文

分类: *nix安全 标签: ,

Intersec内存系列文章–第3部分:管理内存

2014年3月17日 没有评论

原文:http://techtalk.intersec.com/2013/08/memory-part-3-managing-memory/

翻译:童进

 开发人员的视角

在前面的文章中,我们由外在的视角对内存进行了分类、分析,并观察到内存可以按照不同的方式和属性来进行分配。在接下来的文章中,我们将站在开发人员的角度看待内存。

在Intersec,我们所有的软件都是用C语言编写实现的,这也意味着我们得不断与内存管理打交道。我们希望开发人员对各种已有内存池有扎实的知识。 在这篇文章中,我们将概览Linux系统中C程序员获取内存的主要来源,同时还将介绍一些有助于保持程序正确、高效的内存管理规则。

局部性原理

对于内存页,我们已经谈论了很多,它是内核和硬件中的分配单元。CPU采用了更小的寻址单元:cache line。cache line通常是64字节长,这是CPU从主存中读取数据到内部各cache的大小。

最开始CPU没有cache,但CPU性能比内存总线性能发展更迅速。因此为了避免花费太多时间从主内存中读取数据,CPU直接在芯片内增加了少量的内存单元。最初CPU只有单一的、小的cache,但如今可能拥有三级cache。cache越接近CPU,其访问速度越快。离CPU越远,cache越大。下表是2010年酷睿i5-750处理器中每级cache的大小和访问速度:

级别

[……]

阅读全文

分类: *nix安全 标签: , , ,

Intersec内存系列-第2部分:了解进程的内存

2014年3月17日 没有评论

原文:http://techtalk.intersec.com/2013/07/memory-part-2-understanding-process-memory/

翻译:童进

从虚拟内存到物理内存

在上篇文章中,我们介绍了一种进程所占内存分类的方法。通过2个坐标轴划分了4个象限:私有/共享和匿名/文件支持。我们也介绍了共享机制的复杂性和所有内存基本上是由内核回收的事实。

这里我们谈论的都是虚拟内存。所有都是关于(虚拟)内存地址的申请,但申请的地址并不总是立即被内核映射到物理内存。大部分时候,内核会延迟实际物理内存的分配,直到在第一次访问(或第一次写时)……并且分配是以页为单位(每页大小通常是4KB)。此外,一些页面被分配后可能会被换出,这意味着它们会被写入磁盘,以便让其他页面载入RAM中。

因此,想要知道一个进程实际所使用的物理内存(进程的常驻内存)大小真的很困难……内核是系统内真正知道占用内存大小的唯一组件(这可以说是它的一项工作)。幸运的是,内核提供了一些接口可以让你检索到系统或特定进程的一些统计信息。本文将会深入Linux系统工具来分析进程的内存模式。

在Linux上,这些数据通过/proc文件系统提供,/proc/[pid]/中的内容提供了更具体的信息。这些目录(每个进程一个)包含一些伪文件,这些文件是直接从内核检索信息的API入口点。(译者注:proc文件系统是一个伪文件系统。它只存在内存当中,并以文件系统的方式为访问系统内核数据的操作提供接口。)[……]

阅读全文

Intersec内存系列-第1部分:内存类型

2014年3月11日 没有评论

原文:http://techtalk.intersec.com/2013/07/memory-part-1-memory-types/

翻译:童进

引言

这里我们选择C语言作为编程语言,因为它能帮我们实现对程序的完全控制,并达到高的性能。许多人认为,提升性能就是尽可能的减少CPU指令。然而在现代的硬件架构上,性能要考虑的因素复杂得多,绝不仅仅是CPU。程序要处理内存,CPU,磁盘和网络I/O等等。每一项处理都会增加程序的开销,每一项处理必须被正确理解以保证程序的性能和可靠性。

就像程序的复杂度会影响CPU性能一样,影响磁盘读写、网络延迟的因素也很好理解。然而,对内存的影响因素似乎不太好理解。我们的客户经验表明,即便是广泛使用的工具,如top,大多数系统管理员还是无法理解其输出。

本文是关于内存系列文章五篇中的第一篇。我们将要讨论的话题包括:内存的定义、内存是如何管理的、如何阅读工具的输出信息等……这一系列将专注于开发人员和系统管理员都感兴趣的话题。尽管其中大部分规则适用于大多数现代操作系统,我们的讨论更偏向于Linux系统和C语言。

我们不是第一个写关于内存文章的。我们强烈推荐Ulricht Drepper的经典文章《What every programmer should know about memory》。

本文将给出内存的定义,并假定读者至少对地址或者进程等概念有基本的认识。它也会经常涉及到一些内容,如系统调用、用户态与内核态的差异,不过你所需要[……]

阅读全文

分类: *nix安全 标签: , , ,

网络犯罪和网络间谍对经济的影响

2014年3月5日 没有评论

原文:The economic impact of cybercrime and cyber espionage

翻译:李天星(Leo)

一、简介

网络犯罪,网络间谍和其他恶意网络活动被一些人称作是“人类历史上最伟大的财富转移”,还有其他人称之为“14万亿美元的经济舍入误差?”。

大致估算现有的损失————从十几亿美元到几千亿美元————就已经反映了一些问题。有的公司隐瞒了它们的损失而有一些公司还不清楚自己的损失,因为知识产权是很难去衡量其价值的。有些估算是基于其调查结果,但是除非能够细致的构建评估体系,否则最后的估算会很不准确。网络安全调查的一个常见问题就是,有一些精心准备答案回答问题的人,他们的回应将会影响最终结果的准确性。由于数据收集的问题,损失评估都是基于一定的规模和影响力假设,而改变这种(前提)假设,你就会得到不一样的结果,而这些问题让很多评估受到质疑。

恶意网络活动结构

在这个先期报告中,我们从什么应该算作网络犯罪和网络间谍带来的损失开始。我们可以将恶意网络事件分为以下的6个部分:

  • 知识产权和商业机密损失

  • 网络犯罪,每年消耗世界数百万美元

  • 敏感商业信息的泄露,其中包括可能被操纵的股市

  • [……]

阅读全文

用C语言进一步优化Windows Shellcode

2014年2月27日 没有评论

原文:http://www.exploit-monday.com/2013/08/writing-optimized-windows-shellcode-in-c.html

翻译:徐文博

引言

我得首先承认,编写shellcode真是让人郁闷极了。虽然可以利用些小技巧来减小payload的大小,但编写shellcode仍然会错误百出,难以维护。例如,我发现跟踪x86中寄存器的分配,确保x86_64栈的对齐真的是件蛋疼的事。最终我还是腻了,但回头想想:为啥就不能用C写shellcode payload,让编译器和链接器来接管处理剩下的活呢?这样的话,只需写一次payload,就能运用到任何的体系结构上————像x86、x86_64以及ARM这些。同时,也可以获得如下的好处:

1. 运用静态分析工具分析payload

2. 进行单元测试

3. 利用编译器、链接器来优化payload

4. 编译器在速度、大小方面的优化比你在行

5. 利用Visual Studio来写payload,智能化万岁!

考虑到已经写了许多Windows下的shellcode,我决定挑战一下仅用微软工具来生成位置无关的shellcode。可最基本的问题是,微软的C编译器cl.exe无法生成位置无关的代码(除了面向Itanium的Visual C+[……]

阅读全文