用新版本替换Sparkle安全吗

Question

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

Sparkle是Mac应用程序中通常用于管理更新的框架。最近，报告了一次中间人攻击的vulnerability；由于大量使用Sparkle的知名应用程序，世界各地的IT经理开始失眠。

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

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

那么，联系专业人士--用最新版本替换应用程序捆绑包中的旧版本Sparkle.framework有什么缺点(或障碍)？这实际上可以在等待所有受影响的应用程序更新的同时减轻漏洞吗？

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

Answer 1

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

我要说的是，这在一般情况下是不安全的，只需设置sparkle更新变量来禁用所有更新，这将是一个更有效的对策。由于代码库在1.5和1.10之间有了重大变化(查看release notes，框架抛弃了32位，抛弃了旧的Obj-C运行时，抛弃了垃圾收集，并对内部应用程序接口进行了大量更改)，因此将较新的闪光点添加到较旧的应用程序中将是非常危险的，除非您要对每个应用程序进行详尽的测试或检查框架的使用情况/反编译代码。

我一直在编辑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命令中的三个文件夹之外查找应用程序。此外，如果您实际实现此更改，请记住其他用户主文件夹。此外，为了管理多台计算机，您需要推送一个配置文件或更好实现的脚本来解析和禁用这些应用程序：

• https://macmule.com/2016/01/31/sparkle-updater-framework-http-man-in-the-middle-vulnerability/
• https://github.com/arubdesu/extinguish