Linux 内核 “社区” 对待安全的优先级并不高,虽然经历了 2000
年代的多次大规模漏洞利用事件但并没有让 Linus Torvalds 本人改变 “A bug is
bug” 的哲学,由于 Linux 内核的安全问题逐渐影响到了 Android 和 IoT
设备,一次 华盛顿邮报的曝光促使了 KSPP(Linux
内核自防护项目)的成立,KSPP 是由 Linux 基金会旗下的
CII(基础架构联盟)管理,其吸纳了来自诸多大厂商(Google, RedHat, Intel,
ARM 等)的工程师进行联合工作,可惜的是两年的时间过去了,KSPP
大多时候只是在重复的抄袭 PaX/Grsecurity
的各种特性以获得各自雇主那里的
KPI 和 credit,各种混乱的代码合并到了 Linux 主线影响了 PaX/Grsecurity
的正常开发,这也是 PaX/Grsecurity 关闭公开访问 test patch
的主要原因之一。

内核社区应当反思DirtyCow 漏洞

导读编号为 CVE-2016-5195 的漏洞在 Linux
内核社区修复完成后的故事并没有结束,72小时内公开的可作非稳定漏洞利用的
PoC 已经有 9 个。如果是标准版本的内核,写
/proc/pid/mem,vDSO(部分版本)以及常规 ptrace()
方法都可以直接利用,PaX/Grsecurity 内核对于这个 PoC 也难以防御。

针对 ptrace/madvise 做 seccomp
的规则虽然可以减缓攻击进度,但带来性能开销的同时也不能一劳永逸的解决这个问题,如果没有
RBAC 的场景还是建议升级。

图片 1

这个漏洞在自由软件世界是比较罕见的,对 GNU/Linux
服务器构成巨大威胁和风险的同时也成为了 Android root
恶意代码链条(包括一键 root 工具)以及 IoT 入侵的强大助攻。Jonathan
Corbet 的文章提到 Linux
内核社区对待安全的态度需要反思,这个严重漏洞的修复竟然是和 cleanup 的
patch
一起合并到主线的,即使是单独的提交也像往常一样并未提供更多的安全评估信息。

这种不提供公开漏洞信息的做法是在 1990
年代用于防御脚本小子获得更多信息,后来 Linux
基金会的“客户”们并没有提出改变的意见所以一直沿用至今。但 2016
年的互联网环境和 1990
年代有着很大的区别,即使没有公开的漏洞信息攻击者可以凭着对代码提交的理解也可以打造出相应的漏洞利用。

或许在 Linux 内核自防护项目开始 10 个月后遇到了 DirtyCow
并不是件坏事。内核自防护项目尝试移植 PaX/Grsecurity 的一些特性终结掉
Linus Torvlads 的“A bug is bug”流派,而 DirtyCow 有望在生态上让 Linux
基金会的“客户”们向 Linux 内核社区施压,说不定会改变“security through
obscurity”的格局。毕竟今天是一个更开放的年代,个体更注重安全,GNU/Linux,Android
和 IoT 的相关厂商都重度依赖于 Linux 的安全性,RedHat 或者 Linux
基金会在安全方面想要一手遮天相比 2002 年还是困难很多。

原文来自:

本文地址:

漏洞 导读 编号为
CVE-2016-5195 的漏洞在 Linux
内核社区修复完成后的故事并没有结束,72小时内公开的可作非稳定漏…

添加微信公众号《Linux就该这么学》,掌握最新IT资讯动态,免费领取Linux课程以及专业的RHCE考前答疑服务。

最近由 Qualys 曝光的 Stack clash
是一个古老的漏洞利用平面的工程化,这威胁到了几乎所有类 UNIX 系统(包括
GNU/Linux)的安全,当 Linux 内核 x86 的 maintainer 之一 Andy Lutomirski
问及 PaX/Grsecurity
是如何修复时
Linus 直接回复了 Grsecurity 是垃圾,有趣的是当 PaX/Grsecurity 的作者之一
Spender 曝光了一些内核最近的 silent
fix 以后 Linus 居然 “邀请”PaX
team/Spender 直接贡献代码到
Linux 内核代码,这是不大可能发生的,因为今天所谓的内核 “社区”
主要是由一帮大厂商的雇员组成,没有人有义务免费的贡献代码去帮助那些需要从雇主那里获得
KPI 的工程师。

《Linux就该这么学》在线免费阅读地址:

更讽刺的是, stack clash
的部分修复居然来自
PaX/Grsecurity 于 2010 年的代码,Linus 说 PaX/Grsecurity
是垃圾也等同于打 KSPP 的脸,因为 KSPP 还在继续抄袭
PaX/Grsecurity,而针对 Linux
内核的漏洞利用是否大规模被恶代使用只是曝光与否的问题。此外,虽然
Stack clash 的 * EMBARGOED” 从开始到现在已经 1 个月,但至今
CVE-2017-1000370(offset2lib
bypass) 仍然未修复,RedHat 网站上所谓的 “Under
Investigation”
只是继续等待 Linux 主线内核的修复,或许要让 Linux
内核安全有所改善我们需要更多的 stack clash 和 DirtyCow 持续曝光。

图片 2纯手工打造每一篇开源资讯与技术干货,**数十万程序员和Linuxer已经关注**

因为利益的关系,Linux 基金会对自由软件社区和 GPL
已经非常不友好,虽然
Greg K-Hartman 一直强调 Linux 基金会是一个非盈利组织,但一个 NGO 的 CEO
为什么有高达 49 万美金(2014
财年)的年薪,也没人知道为什么
Greg 本人会有 Google 的邮箱(拿 Linux 基金会和 Google
双薪水?),Linux
内核本来有一次改善安全的机会,可惜 Linux 基金会的市场 PR
需求搞砸了整件事。HardenedLinux 社区在这里建议所有的 GNU/Linux
用户请认真重新评估数据资产的重要性所对应的安全等级。”

导读 编号为 CVE-2016-5195 的漏洞在 Linux 内核社区修复完成后的故事并没有结束,72小时内公开的可作非稳定漏洞利用的 PoC 已经有 9 个。如果是标准版本的内核,写 /proc/pid/mem,vDSO(部分版本)以及常规 ptrace() 方法都可以直接利用,PaX/Grsecurity 内核对于这个 PoC 也难以防御。

来源:Solidot

针对 ptrace/madvise 做 seccomp
的规则虽然可以减缓攻击进度,但带来性能开销的同时也不能一劳永逸的解决这个问题,如果没有
RBAC 的场景还是建议升级。

图片 3

这个漏洞在自由软件世界是比较罕见的,对 GNU/Linux
服务器构成巨大威胁和风险的同时也成为了 Android root
恶意代码链条(包括一键 root 工具)以及 IoT 入侵的强大助攻。Jonathan
Corbet 的文章提到 Linux
内核社区对待安全的态度需要反思,这个严重漏洞的修复竟然是和 cleanup 的
patch
一起合并到主线的,即使是单独的提交也像往常一样并未提供更多的安全评估信息。

这种不提供公开漏洞信息的做法是在 1990
年代用于防御脚本小子获得更多信息,后来 Linux
基金会的“客户”们并没有提出改变的意见所以一直沿用至今。但 2016
年的互联网环境和 1990
年代有着很大的区别,即使没有公开的漏洞信息攻击者可以凭着对代码提交的理解也可以打造出相应的漏洞利用。

或许在 Linux 内核自防护项目开始 10 个月后遇到了 DirtyCow
并不是件坏事。内核自防护项目尝试移植 PaX/Grsecurity 的一些特性终结掉
Linus Torvlads 的“A bug is bug”流派,而 DirtyCow 有望在生态上让 Linux
基金会的“客户”们向 Linux 内核社区施压,说不定会改变“security through
obscurity”的格局。毕竟今天是一个更开放的年代,个体更注重安全,GNU/Linux,Android
和 IoT 的相关厂商都重度依赖于 Linux 的安全性,RedHat 或者 Linux
基金会在安全方面想要一手遮天相比 2002 年还是困难很多。

原文来自:

本文地址:

图片 4

让您学习到的每一节课都有所收获

《Linux就该这么学》是由资深运维专家刘遄及全国多名红帽架构师(RHCA)基于最新RHEL7系统共同编写的高质量Linux技术自学教程,极其适合用于Linux技术入门教程或讲课辅助教材。

刘遄老师QQ:5604241

☀ 学员助教QQ:5604674

☀ Linux技术交流A群(满):560843

☀ Linux技术交流B群:340829

☀ Linux技术交流C群:463590

☀ 官方站点:www.linuxprobe.com

☀ 电脑在线阅读效果更佳:

图片 5

按住图片3秒,即可自动关注。

点击左下角查看更多热门技术

添加微信公众号《Linux就该这么学》,掌握最新IT资讯动态,免费领取Linux课程以及专业的RHCE考前答疑服务。

《Linux就该这么学》在线免费阅读地址:

阅读原文: