用更新版本替換Sparkle安全嗎

&tldr; 什麼阻止我們用新的Sparkle.framework替換舊的Sparkle.framework？用更新版本替換Sparkle安全嗎

Sparkle是Mac OS X應用程序中用於管理更新的常用框架。最近有報道稱中間人攻擊的vulnerability;由於衆多使用Sparkle的知名應用程序，全球IT經理們開始失眠。據報道，一些受影響的應用程序（如VLC）已經發布了修復程序。但是，由於Sparkle已經存在了很長時間，有很多其他應用程序不再積極開發，但它們仍然容易受到同樣的問題。我們已經遇到過這樣一個應用程序。

因爲Sparkle.framework是一個運行時框架，所以理由是在應用程序捆綁包中用較新的（1.13.1）代碼替換舊的（在許多情況下爲1.5或1.6）代碼將允許應用程序在很多情況下運行。到目前爲止，我們的輕度測試對於兩個人來說是令人鼓舞的兩個（意思是，應用程序可以開始，並且會檢查更新）;但在鼓勵樂觀主義者的同時，這絕不是一個全面的答案。

因此，接觸到專業人員 - 在最新版本的應用程序包中替換舊版Sparkle.framework的缺點（或障礙）是什麼？這是否可以在等待所有受影響的應用程序更新時減輕漏洞？

根據當前使用的Sparkle的版本以及哪個版本支持哪些函數調用，答案可能會改變。這也取決於是否有任何函數在Sparkle的新版本中被棄用，這是我不知道的。

來源

2016-02-12 Kent

有沒有弊端;舊版本的Sparkle.framework應該被替換，或者至少在沒有使用的情況下切換到https。 –

原始問題可能還不夠清楚;但是，我指的是在已下載的應用中替換Sparkle.framework，而不是在我們正在開發的應用中。 – Kent

如果您是應用程序的開發人員，請絕對升級該框架並推出更新。從討論在應用程序包中替換閃爍的文本中，我將假定您正在考慮修復已安裝的多個應用程序。

我會說這根本就不安全，它將是一個更有效的對策，只需設置閃爍更新變量來禁用所有更新。由於代碼庫在1.5到1.10之間發生了重大變化（查看了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命令的三個文件夾以外的應用程序。另外，如果您實際執行此更改，請記住其他用戶主文件夾。此外，用於管理多臺計算機，你要推的個人資料或更好的執行腳本來分析和禁用這些應用程序：

來源

2016-02-12 20:49:24 bmike

在開發人員方面，我同意更新是一件容易的事情。您對我的問題的意圖是正確的 - 主要關注在其他地方下載的用戶計算機上的應用程序。我不會嘗試用frankenstein sparkle版本實際運行更新;但是，就減輕mitm威脅而言，這似乎是合理的。不過，SUFeedURL是一個很好的選擇。（但是，我知道至少有一個應用程序將該URL嵌入源代碼中，並且無法通過plist訪問）。現在我暫時停止對我的質量1.13更換...... – Kent

用更新版本替換Sparkle安全嗎

回答

相關問題