存档

‘*nix安全’ 分类的存档

时尚时尚最时尚的缓冲区溢出目标

2015年3月4日 没有评论

原文:《Modern Overflow Targets》 By Eric Wimberley,Nathan Harrison

翻译:taskiller

在当今的操作系统中,内存缺陷漏洞已经越来越难挖掘了,栈保护措施已经使原来的缓冲区溢出利用方法(将NOP块和shellcode写入到缓冲区中,并用缓冲区内的地址覆盖EIP所指向的地址)失效了。如果没有某种程度的信息泄露,在地址空间分布随机化(ASLR)和栈cookies的双重保护下,用传统方法实际上已经很难对远程系统执行有效的溢出攻击了。

不过,现在仍存在可被利用的栈输入/输出漏洞。本文描述了一些常用缓冲区溢出技术,这些技术不会触发栈的__stack_chk_fail保护,或至少到目前为止还有效的技术。本文我们不再利用新技术通过修改EIP来修改程序的执行流程,而是将精力集中到一系列新的目标中。同时,本文也会讨论GCC 4.6及之前版本中未出现在任何文档中的函数安全模式(function safety model)。

GCC ProPolice记录的异常

根据函数安全模型的ProPolice文档,以下情况不会被保护:

  • 无法被重新排序的结构体,以及函数中的指针是不安全的。

  • 将指针变量作为参数时是不安全的。

  • 动态分配字符串空间是不安全的。

  • 调用trampoline代码的函数是不安全的[……]

阅读全文

CTF领域指南

2015年2月15日 没有评论

原文:https://trailofbits.github.io/ctf/

翻译:做个好人

译者声明:本文翻译自美国trailofbits团队发布在Github上的《CTF Field Guide》手册,我们已与对方联系获得翻译授权,由于手册内容尚在更新过程中,故有部分缺失。如有翻译不当之处,请与我们联系更正:@IDF实验室。

“Knowing is not enough; we must apply. Willing is not enough; we must do.” (仅仅知道还不够,我们必须付诸实践。仅有意愿还不够,我们必须付诸行动。)

—— Johann Wolfgang von Goethe

欢迎!

很高兴你能来到这里,我们需要更多的像你这样的人。

如果你想拥有一种能够自我防卫的生活,那就必须像攻击者那样思考。

所以,学学如何在夺旗比赛(CTF)中赢得比赛吧,这种比赛将专业的计算机安全活动规则进行了浓缩,且具有可客观评判的挑战题。CTF比赛趋向关注的主要领域是漏洞挖掘、漏洞利用程序构建、工具箱构建和可实施的谍报技术(tradecraft)。

无论你想赢得CTF比赛,还是想成为一名计算机安全专家,都至少需要擅长这些方面中的其中之一,理想情况下需要擅长所有这些领域。

这就是我们编写此手册的目的。

在这些章节中,你[……]

阅读全文

电子取证之Linux PCI分析

2014年5月28日 没有评论

原创:4ll3n

上篇文章为大家讲解了在Linux ext4分区下如何恢复误删除文件的整个过程,每次坐在电脑前,把手机和电脑通过USB接口进行连接,为手机充电。总在想一个问题:“手机和电脑连接后,系统又做了点什么?”这就是整篇文章开始的源泉。

现在让我们走进系统,看看它的运行原理:

linux pci 01

终端命令lsusb,分别列举了挂载设备的Bus、Device、ID、Name,什么是ID呢?设备的ID由Vendor、ProdID组成。

linux pci 02

设备每次的挂在ID值在主机上是个唯一的指纹,这组数据在Command下如何获取呢?可以使用usb-devices获取所有在主机上以USB接口为主的所有参数。

Command给出的参数列表来自于:

linux pci 03

图中给出了大量文本文件和对应的目录名,来验证下,数据是否正确:

linux pci 04

看到图片有五个编号以1-8开头,以1.x结尾的文件目录,它们对应的是什么呢?

linux pci 05

1-8:1.0对应这If#=0,依此类推,而如何获取图片中的Name?

linux pci 06

进入目录后,可以发现其中有个名为:interface,对进行cat,就能得到上图中的接口名。

 

讲到这里,我们还有没结束,继续往深处挖掘,看看它们其他的关联文件。

linux pci 07

在/run/udev/links下,找到了系[……]

阅读全文

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文件系统是一个伪文件系统。它只存在内存当中,并以文件系统的方式为访问系统内核数据的操作提供接口。)[……]

阅读全文