这是一个创建于 4504 天前的主题，其中的信息可能已经有所发展或是发生改变。
懒人版本：
漏洞描述：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 的攻击在数量和质量上没有那么到位而已。
漏洞描述：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 的攻击在数量和质量上没有那么到位而已。
 |
1
cyfdecyf 2012-07-28 15:39:02 +08:00
昨天刚刚买了 CCC 3.5，之前还不知道有这个漏洞。3.5 版本是通过应用 SMJobBless 来解决之前存在的问题的么？
|
 |
2
zhuang OP @cyfdecyf
这个问题我没法回答，想知道是否调用 SMJobBless 只能通过逆向手段来确认。另外，调用 SMJobBless 还不够，重要的是通过 code sign 方式实现主程序和 helper 的信任关系。 但是，可以认为 ccc 3.5 版本依旧存在此漏洞，原因是代码签名会在 Info.plist 中留下 SM 相关条目，而 ccc 3.5 的配置文件中找不到相关的信息。 |
Select Language