懒人版本:
漏洞描述: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 的攻击在数量和质量上没有那么到位而已。