1

&tldr; 是什么阻止我们用新的 Sparkle.framework 替换旧的 Sparkle.framework？

Sparkle是 Mac OS X 应用程序中常用来管理更新的框架。最近，有人报告了中间人攻击的漏洞；而且，由于大量使用 Sparkle 的知名应用程序，世界各地的 IT 经理开始失眠。

据报道，一些受影响的应用程序，如 VLC，已经发布了修复程序。然而，由于 Sparkle 已经存在了这么久，可能还有许多其他应用程序不再积极开发，但仍然容易受到相同问题的影响。我们已经遇到过一种这样的应用程序。

由于 Sparkle.framework 是一个运行时框架，因此在应用程序包中用较新的 (1.13.1) 代码替换旧的（在许多情况下为 1.5 或 1.6）代码将允许应用程序在许多案例。到目前为止，我们的轻量级测试是令人鼓舞的二对二（这意味着，应用程序可以启动，并且会检查更新）；但是，虽然对乐观主义者来说是鼓舞人心的，但这绝不是一个全面的答案。

那么，联系专业人士——用最新版本替换应用程序包中旧版本的 Sparkle.framework 有哪些缺点（或障碍）？这实际上是否可以在等待所有受影响的应用程序更新时减轻漏洞。

答案可能会有所不同，具体取决于当前使用的 Sparkle 版本，以及哪个版本支持哪些函数调用。这还取决于新版本的 Sparkle 中是否已弃用任何功能，这是我不知道的。

4

1 回答 1

1

如果您是应用程序的开发人员，请绝对升级框架并推出更新。从讨论“在应用程序包中”替换 sparkle 的文本中，我假设您正在考虑修复已安装的几个应用程序。

我会说一般来说这根本不安全，将 sparkle update 变量设置为禁用所有更新将是一种更有效的对策。由于 1.5 和 1.10 之间的代码库发生了重大变化（查看发行说明，框架放弃了 32 位，放弃了旧的 Obj-C 运行时，放弃了垃圾收集并对内部 API 进行了大量更改），这将是非常危险的除非您要彻底测试每个应用程序或检查框架的使用/反编译代码，否则将更新的火花塞入旧应用程序。

我一直在编辑 Info.plist 文件以将SUFeedURL键更改为指向https://172.0.0.1/app-name.xml的所有具有 http 感觉的应用程序都容易受到控制受损网络的不良行为者的攻击.

如果您愿意，您也可以禁用这些应用程序的自动检查。这是针对 sparkle 框架和非 https 提要源的快速而肮脏的单行检查：

find /Applications ~/Applications /usr -name Sparkle.framework -exec echo {} \; -exec defaults read {}/../../Info.plist SUFeedURL 2>/dev/null \; | grep -vw ^https

您可以mdfind kind:app检查我输入 find 命令的三个文件夹之外的应用程序。此外，如果您实际实施此更改，请记住其他用户主文件夹。此外，为了管理多台计算机，您需要推送配置文件或更好实施的脚本来解析和禁用这些应用程序：

于 2016-02-12T20:49:24.660 回答