carbon copy cloner 安全警示,兼谈 Mac 安全

2012-07-28 13:06:48 +08:00
 zhuang
懒人版本:

漏洞描述:ccc(<=3.5) 可能被用作恶意软件本地提升权限。
解决办法:在确保 ccc 未被修改的前提下,将 /Applications/ ccc 的目录所有者改为 root:root



细节版本:

我也是刚听说这个漏洞,经过在某 irc 中询问得知,这个攻击方法早在几个月前就被好几个 malware 应用,实际上不止 ccc 有这个漏洞,但是因为 ccc 的用户量和它作为备份工具的频繁使用成为最合适的突破口。

Mac 系统应用程序安装通常是“拖放”操作完成,当前用户将程序复制到 /Applications 目录中,新的 app 目录所有者即为当前用户。如果恶意软件被执行,可以静默地修改任意属于当前用户的文件,这里就包括以拖放方式安装的 ccc 程序。ccc 在执行全盘备份时,需要获取 root 权限读取硬盘,这一提权操作由 ccc_helper 实现。恶意软件通过修改 ccc_helper 文件,在用户下一次执行备份操作授予 root 权限时,即可达到提权目的。(所以更好的预防措施是,将整个 /Applications 目录所有文件改为 root:root 所有,阻止恶意软件修改)



技术细节版本:

漏洞的根源在于,ccc 使用的特权代码分离是旧的 BetterAuthorization 模型,苹果在 10.6 引入 ServiceManagement 框架,应用新 SMJobBless 模型的应用程序不再受此攻击方法的影响,ccc 的作者在 http://help.bombich.com/discussions/questions/10307-max-os-x-is-not-responding-to-cccs-request-to-perform-a-privileged-task 提到没有转换到新模型的原因是旧版本支持工作量过大造成的。



一点感想:

研究这个漏洞的过程,让我更加确信,在安全性上,Mac 是比 Windows/*nix 先进的操作系统。

Windows 直到 Vista 才尝试引入 Mandatory Access Control 这一基本安全模型,结果最终实现 UAC 还是个半成品,安全方面就不多解释了。

Mac 是我知道的第一个尝试“代码级别权限分离”的操作系统。核心思想是,需要特殊权限的操作委托一个由操作系统特殊管理的进程(helper)来执行,普通程序代码仍然以受限权限执行。Mac 在 10.5 中对这一编程模型提供了系统级支持。这是 2007 年。
由于这一设计比较原始,存在 ccc 例子中的提权漏洞,因而后续的改进引入了代码签名机制,使得只有授权的应用程序才可以和 helper 通讯并委托执行特权指令。正式发布时间是 2009 年的 10.6 版本。
2011 年的 10.7 版本中,此模型进一步优化,可以由 XPC API 由 GCD 进行优化,更加减轻了开发者的工作量。

*nix 范围内,确实基于用户和组的权限管理机制以及 MAC 机制都是成功的创造,而且理论上完美的 MAC 规则意味着无懈可击的安全性,*nix 几乎是大部分新技术的发源地,比如 aslr 等等。但 *nix 的问题是,过度分裂使它对于开发者不够友好。长期以来,*nix 安全编程的准则只有一句话“权限最小化”,而实际的实现手段只有用户组机制,因为只有这一机制被普遍实现了。*nix 也不是没有进步,像“代码级别权限分离”的模型,也在向 Mac 学习的。linux 中最早提及这一概念的是 https://www.cr0.org/paper/jt-ce-sid_linux.pdf 作者是 Google 的研究员,时间是 2009 年。

这只是安全技术中的一点点细枝末节,但其中的时间点足够反映出先进技术的所在。另一方面,操作系统提供支持仅仅是一个开始,整个软件生态过渡到新技术需要开发者的跟进,而一个对开发者友好的平台才是真正有竞争力的平台。举个例子,aslr 技术本身是来自于 linux 的,iOS 在操作系统支持之后,以 Xcode 更新编译器开发环境的方式,使得 4.3 之后的系统实现了完整过渡。而源自 linux 的 Android 系统,直到 4.1 才刚有系统级支持,但以 Android 工具链更新和生态演进情况来看,实现完整过渡还要很长时间。



PS
Mac 只是相对先进的那个操作系统,但在安全性这个问题上,Mac 像 Windows 一样存在着大量的问题,只是针对 Mac 的攻击在数量和质量上没有那么到位而已。
5227 次点击
所在节点    信息安全
4 条回复
cyfdecyf
2012-07-28 15:39:02 +08:00
昨天刚刚买了 CCC 3.5,之前还不知道有这个漏洞。3.5 版本是通过应用 SMJobBless 来解决之前存在的问题的么?
zhuang
2012-07-29 02:30:16 +08:00
@cyfdecyf
这个问题我没法回答,想知道是否调用 SMJobBless 只能通过逆向手段来确认。另外,调用 SMJobBless 还不够,重要的是通过 code sign 方式实现主程序和 helper 的信任关系。
但是,可以认为 ccc 3.5 版本依旧存在此漏洞,原因是代码签名会在 Info.plist 中留下 SM 相关条目,而 ccc 3.5 的配置文件中找不到相关的信息。
cyfdecyf
2012-07-29 13:28:27 +08:00
@zhuang 多谢!再看了一边你给的 CCC support 的链接,从作者的最后一个回复来看 3.5 应该没有用 SMJobBless。而且至少要到 CCC 放弃对 Tiger, Leopard 的支持之后才可能换。

原帖有一点 typo,应该是 chown -R root:wheel,mac 上 gid 0 的组是 wheel。

改所有者后,更新 CCC 可能要再改回来吧。
cyfdecyf
2012-07-29 13:28:28 +08:00
@zhuang 多谢!再看了一边你给的 CCC support 的链接,从作者的最后一个回复来看 3.5 应该没有用 SMJobBless。而且至少要到 CCC 放弃对 Tiger, Leopard 的支持之后才可能换。

原帖有一点 typo,应该是 chown -R root:wheel,mac 上 gid 0 的组是 wheel。

改所有者后,更新 CCC 可能要再改回来吧。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/43695

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX