HP 的 SWHelper 為何被 XPC 取代?
摘要
這份報告分析在 macOS 版 HP Easy Start(v2.16.0, Build 251010) 中發現的三個高嚴重性漏洞,分別影響軟體交付 pipeline、具權限下的暫存檔案處理,以及傳輸安全態勢。這三個問題都在 Build 2.16.7.260722 中,依廠商公告 HPSBPI04124 完成修補 [1] [2] 。我們重現關鍵的程式碼證據,對利用序列建模,並檢視 HP 作為修復所採用的現代化特權 helper 架構。
1. 簡介
印表機設定工具是讓一般使用者授予第三方軟體管理權限的常見途徑。HP Easy Start(
com.hp.hp-easy-start
)正是這樣一款工具:它在 macOS 上下載、暫存並安裝印表機軟體套件,並在單次使用者核准的認證提示後,週期性地呼叫具權限的操作。由於應用程式位於網路取得與特權安裝的交會處,其權限邊界的弱點會造成極大的影響
[1]
。
受檢的 Build 2.16.0 暴露了三個不同但相互作用的弱點:在 root 身分執行的 Uninstaller 中可預測的暫存檔案路徑(
CVE-2026-12555
,CWE-379,CVSS 4.0 7.7)、在元件取得路徑上未維護且支援 FTP 的下載堆疊(
CVE-2026-12554
,CWE-1104,CVSS 4.0 8.5),以及全域放寬的 App Transport Security 政策結合明文 FTP 後援(
CVE-2026-12556
,CWE-319,CVSS 4.0 7.7)
[1]
[2]
。第四項觀察涉及
SWHelper
特權 helper 中已棄用的
AuthorizationExecuteWithPrivileges
API,被記錄為具風險的設計,但刻意未指派 CVE,因為未展示端到端的正式環境 Race Condition
[1]
。
2. 威脅模型
分析中納入了兩類攻擊者。一類
本機未具權限使用者
共用該機器,可在全域可寫的
/tmp
與
/private/tmp
中建立名稱,但無法偽造管理員密碼;反之,攻擊者預先佈置檔案系統,使經授權的提權寫入至攻擊者選定的路徑。一類
網路位置攻擊者
共用 LAN 網段或控制 DNS,當明文後援傳輸可觸及時取得干擾能力
[1]
。
3. 發現 1 — CVE-2026-12555:經由符號連結跟隨的特權檔案寫入
HP Uninstaller 是一支透過 AppleScript 管理流程(
do shell script ... with administrator privileges
)執行的 Ruby 腳本,因此在使用者核准標準提示後,其檔案操作以 root 身分執行。它會開啟共用暫存目錄中靜態定義、可預測的路徑,而未阻擋符號連結:
- # Log file 路徑(靜態定義 — 在所有安裝之間皆可預測)
- $installerLogfile="/tmp/com.hp.uninstaller-log.txt"
- def puts(msg)
- logMsg="#{currentDate} HP Uninstaller: #{msg}"
- # File::APPEND 搭配 mode 0666:若該路徑是由本機攻擊者預先放置的
- # 符號連結,則 open() 會跟隨它,並將 HP 產生的 log 內容
- # 以 ROOT 權限附加到攻擊者選定的目標。
- File.open($installerLogfile,
- File::CREAT | File::APPEND | File::RDWR, 0666) do |f|
- f.puts "#{logMsg}"
- end
- end
- # Lock file 路徑 — 此 Build 的 UUID 在所有安裝之間皆相同
- # (並非每次安裝唯一),因此該路徑完全可預測。
- file = File.open("/private/tmp/com.hp.software.96EB4066-D8CA-4343-ACC7-4D3CCFF4FB01",
- File::RDWR|File::CREAT, 0666)
- file.flock(File::LOCK_EX)
研究人員刻意將所產生的原始能力描述為 特權檔案修改 ,而非任意檔案寫入:目的路徑由攻擊者控制,但附加的內容是由 HP 自身的 log 字串所產生 [1] 。後續的權限提升需要適合特定環境的目標,且並非自動發生。完整的利用序列摘要如下:
修補指引包括安全暫存檔案 API(
mkstemp()
、
mkdtemp()
)、以
O_NOFOLLOW
/
O_EXCL
開啟、對已開啟的 descriptor 以
fstat()
驗證,以及避免在全域可寫目錄中進行特權記錄
[1]
。HP 修復後的 Build 完全移除了有漏洞的 Uninstaller bundle
[1]
[2]
。
4. 發現 2 — CVE-2026-12554:未維護的 OSPFTP 下載堆疊
對主 binary 的靜態分析確認了一組
OSPFTP*
類別家族被接入元件安裝,包括明確的後援 URL scheme 處理:
# Class and selector evidence recovered from the 2.16.0 main binary.
# The fallback architecture means: if the primary download scheme fails,
# the application can fall back to cleartext FTP for the SAME component.
OSPFTPDownloadManager
OSPFTPDownloadOperation
OSPFTPFileDownloadTask
startDownloadingWithFallbackURLSchemes:toDestinationFolderURL:
makeFileDownloadWithSourceURL:destinationFolderURL:fallbackURLSchemes:
"Supported fallback URL schemes %@"
"FtpURL"
此問題被歸類為 CWE-1104(使用未維護的第三方元件),問題不在於每次安裝在正常路徑上都會使用 FTP,而在於一個未維護且支援 FTP 的元件仍存在於特權軟體交付表面上,擴大了 GUI 後續交給特權安裝程式之套件的替換介面
[1]
。修復後的 Build 移除了 OSPFTP 類別與字面上的
ftp://
標記;下載改至 HTTPS 端點
[1]
。
5. 發現 3 — CVE-2026-12556:經由放寬 ATS 與 FTP 後援的明文傳輸
應用程式全域放寬 macOS App Transport Security(ATS):
"NSAppTransportSecurity" => {
# Blanket relaxation: permits unsecured HTTP loads that ATS would
# otherwise block, for every domain the app contacts.
"NSAllowsArbitraryLoads" => true
}
該分析對範圍相當謹慎:
NSAllowsArbitraryLoads=true
本身
並非憑證驗證繞過;憑證政策是另一個獨立議題(該 binary 另外暴露了
_validateCertFlag
/
_validateCertificate
切換開關,被註記為 CWE-295 evidence,但不是公開 CVE)。反之,放寬的政策結合發現 2 的 FTP 後援,讓 Network adversary 在主要 scheme 可被誘導失敗時,取得對套件的明文替換機會
[1]
。修補措施將 ATS 收緊為僅允許每個網域的例外,並從軟體路徑中刪除了 FTP
[1]
[2]
。
6. 設計註記 — SWHelper 中已棄用的特權 API
除了三個 CVE 之外,Build 2.16.0 隨附
SWHelper
,這是一個特權 helper,透過長久已棄用的
AuthorizationExecuteWithPrivileges
API 以 root 身分安裝套件,Apple 警告該 API 可能以 root 權限執行任意工具。還原的靜態證據:
# Static strings recovered from Contents/MacOS/SWHelper (2.16.0): # - Legacy authorization imports and deprecated execution API # (AuthorizationCreate / AuthorizationCopyRights / dlsym / # AuthorizationExecuteWithPrivileges) # - Right requested: system.privilege.admin # - Parent validation: spctl -a -t exec (executability check of the # calling app — NOT package install-type validation) # - Shared predictable path string reused from the Uninstaller: /private/tmp/com.hp.software.96EB4066-D8CA-4343-ACC7-4D3DCCFF4FB01 # - Package checks: /usr/sbin/pkgutil --check-signature, OSPPackageSignatureChecker # - Final install handoff: /usr/sbin/installer
以路徑為導向的先驗證後執行設計,典型上容易受到 TOCTOU Race Condition 影響。然而,套用嚴格的證據門檻(暫存位置、簽章檢查器實際驗證的內容、何時取得權限、
/usr/sbin/installer
最終開啟哪個檔案系統物件,以及未具權限的寫入者能否在該時間窗內變更它),研究人員
並未
展示端到端的正式環境套件替換 Race Condition,因此僅將其發表為具條件可利用性的風險設計
[1]
。
7. 修補後的架構
Build 2.16.7(260722)完全移除了
SWHelper
與
AuthorizationExecuteWithPrivileges
,引進
com.hp.easystart.helper
:一個由
SMAppService
管理的 LaunchDaemon,透過
NSXPCConnection
通訊,以程式碼簽章要求限制用戶端(
anchor apple generic and identifier "com.hp.hp-easy-start" and certificate leaf[subject.OU] = "6HB5Y2QTA3"
),並在呼叫
/usr/sbin/installer
之前,對已開啟的檔案 descriptor 驗證套件 SHA-256
[1]
。這將完整性驗證綁定到安裝程式後續取用的同一個 inode,封閉了可變路徑的缺口:
8. 與相關工作的比較
這些發現遵循一個有充分文獻記載的模式:殘留的特權 artifact 成為本機權限提升的原始能力。先前對 macOS daemon 生命週期缺陷的分析顯示,
/Library/LaunchDaemons
中孤兒化的
plist
檔案,讓攻擊者能放置會在開機時或 on-demand 以 root 權限啟動的可執行檔
[3]
。同樣地,由安全關鍵指標的非原子更新所引發的 Kernel 層級 Race Condition,說明了先檢查後使用的時間窗如何破壞權限邊界
[4]
。CVE-2026-12555 是使用者空間的類似案例:一個由特權 process 取用的可預測共用路徑。值得注意的是,HP 案例也展現了有紀律的揭露衛生——已棄用的 SWHelper 路徑被發表為設計觀察,而非誇大的 CVE 主張,這是更多漏洞研究應採用的標準
[1]
。
9. 結論
HP Easy Start 中的三個 CVE 都追溯到同一個主題:特權操作取用受攻擊者影響的輸入——可預測的暫存路徑、未維護的後援傳輸,以及放寬的傳輸政策。廠商的修補於 2026-07-29 由研究人員驗證,展示了現代參考設計:SMAppService 管理的 helper、具程式碼簽章用戶端限制的 XPC,以及綁定到已開啟檔案 descriptor 而非可變路徑的完整性驗證 [1] [2] 。