首页 文章

用更新的版本替换Sparkle是否安全

提问于
浏览 次
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中是否已弃用任何函数，这是我不知道的 .

macos sparkle

1 回答

  • 1

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

    我会说这一般都不安全，只是设置闪烁更新变量以禁用所有更新将是一个更有效的对策 . 由于代码库在1.5和1.10之间发生了重大变化（查看release notes框架丢弃了32位，抛弃了旧的Obj-C运行时，抛弃了垃圾收集并对内部API进行了大量更改）因此风险很大除非你要详尽地测试每个应用程序或检查框架的使用/反编译代码，否则将更新的闪光推送到更旧的应用程序中 .

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

    如果您愿意，也可以禁用这些应用程序的自动检查 . 这是一个快速而肮脏的一行检查闪烁框架和非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命令的三个文件夹之外的应用程序 . 此外，如果您实际实现此更改，请记住其他用户主文件夹 . 此外，为了管理多台计算机，您需要推送配置文件或更好的实现脚本来解析和禁用这些应用程序：

    回复于

相关问题