如何看待 Steam 最近爆出的 0day 漏洞？
由SteamCN的壇友轉載，來源於Reddit的新鮮漏洞。
Steam Windows客戶端存在0day漏洞?steamcn.com這個漏洞的威脅如何？利用難度如何？作為普通玩家有沒有切實可行的辦法去防這個漏洞？
剛讀完 Vasily Kravets 的漏洞分析，隨手答一下好了。
先上總結：這次 Steam 客戶端爆出的漏洞是一個許可權提升類的漏洞，相當於在你的系統裏提前開好了後門。本來木馬病毒在你的電腦上可能什麼許可權都沒有，利用了這個漏洞之後就能直接竊取到最高許可權，算是一個比較嚴重的漏洞。
利用難度嘛，十到十五分鐘，取決於黑客打字速度有多快了。如果有提前寫好的攻擊腳本的話，那就是一秒不到。不過漏洞利用的前提是黑客有權在你的電腦上執行代碼，所以對於普通用戶來說，只要你不去下載一些可疑的軟體、不去點擊一些可疑的鏈接，那應該就不會受到攻擊。如果你一定要下載可疑軟體的話，最好使用虛擬機，或者乾脆卸載掉 Steam、禁用Steam的後臺服務。
好，解答完喫瓜網友最關心的問題之後，我要開始吐槽了。
在這次 Steam 事件中，這個安全漏洞根本不是最嚴重的問題，最嚴重的問題是 Steam 運營公司 Valve 驚人的愚蠢，雙倍的愚蠢。
首先蠢的是這個漏洞的成因。Steam的後臺服務不知道為什麼，會把註冊表中「HKLMSoftwareWow6432NodeValveSteamApps」項下的子項全部設置成「所有用戶可讀可寫」。黑客在這個項下創建一個軟連接，把連接指向註冊表中的任何一處位置，就能藉助Steam把這處位置改成可讀可寫，然後改註冊表提權就可以了。
這個蠢到讓人髮指的設計揭示出一個驚人的事實：雖然 Valve 的程序員對自己改註冊表的本事很自信，抬手就是什麼「All User Full Control」，但他們可能連軟連接這個基本概念都沒聽過，不然他們決然寫不出這種邏輯來。
其次蠢的是 Valve 公司的應對。對於這樣一個板上釘釘的提權漏洞，連攻擊代碼都已經被人發在網上了，Valve 公司居然還能死鴨子嘴硬，一邊嚷嚷著什麼「這個漏洞沒有威脅，黑客根本攻擊不了」，一邊威脅 Vasily Kravets 不許公佈漏洞。
既然這個漏洞攻擊不了，公佈就公佈了唄，您擱那害怕什麼呢？
歸根結底，Valve 根本不在乎用戶的電腦安全，也不想解決問題，他們只想解決提出問題的人。如果 Valve 堅持用這種態度做產品，我相信他們一定能夠成為世界最大的電腦病毒發行平臺，讓上億用戶足不出戶就能享受到「高投入、高質量、高回報」的3A級病毒大作。
補充：聽說 Steam 的 Beta 版已經在修復漏洞了，戳這裡可以看到另一個匿名答主寫的升級教程和禁用服務教程。
Valve的態度麼，還是一如既往的傲慢……
批判的話，上面大佬說完了，我們想想該怎麼做吧，今天在新聞大量爆出後，Valve已經開始在beta版的客戶端中修復這一漏洞了：
1.你在steam設置中開啟，加入Steam Bete測試
2. 你若不想使用Beta客戶端（畢竟這貨可以一天更新三次），那麼你可以手動禁用steam client service
方式：打開控制面板-管理工具-組件服務-服務（本地），找到steam client service,右鍵屬性，啟動類型改為禁用
當然，禁用服務存在一定的影響性，可能導致部分聯機遊戲無法進行聯網
其實，說時候現階段影響不是特別大（不隨意添加奇怪的遊戲/激活CDK），但是有點搞不懂正式版客戶端（截止8.12）為什麼還及時跟進Beta呢？
我更新一下這個漏洞事件的後續：
正如高票 @Gh0u1L5 所說Beta版修復了Kravets公開的提權漏洞。很快正式版也修復了這個漏洞。我看了Kravets寫的write-up之後，決定自己找一下能不能繞過修復。一找果然能輕易繞過。
Valve的修復是不再調用RegSetKeySecurity設置「HKLMSoftwareWow6432NodeValveSteamApps」的子鍵為Users可讀寫。但是使用Process Monitor，我發現Steam Client Service在啟動是會複製C:Program Files (x86)SteaminSteamService.dll和C:Program Files (x86)SteaminSteamService.exe到C:Program Files (x86)Common FilesSteam下，替換掉原本的SteamService.dll和SteamService.exe。
而C:Program Files (x86)Steamin是可以被Users寫入的。所以思路是用舊版帶漏洞的SteamService.dll/.exe替換掉已更新的SteamService.dll/.exe。然後啟動Steam Client Service。這樣它啟動時使用的就是有漏洞的版本，接下來我們就又能用原來的PoC提權了。
由於Valve根本不關心本地提權漏洞，所以我發現繞過之後沒有提交，並且直接公開細節在了GitHub上：
Bypassing the Fix for Steam Reg-symlink Privilege Escalation Vulnerability?xiaoyinl.github.io
Kravets幫我給這個漏洞申請了一個CVE：CVE-2019-15315
隨後Kravets又發現了新的Steam提權0day（CVE-2019-15316）：
One more Steam Windows Client Local Privilege Escalation 0day?amonitoring.ru
終於Valve決定修復這些提權0day啦：
https://steamcommunity.com/groups/SteamClientBeta#announcements/detail/1599262071399843693?steamcommunity.comBeta版已經修復了所有公開的0day，建議用戶按 @Neko Fox 說的方法更新Beta版。
Valve後來承認了自己忽略Kravets的漏洞是錯誤的。同時修改了HackerOne上的漏洞項目規則，明確規定本地提權是有效漏洞。
Valve - Bug Bounty Program | HackerOne?hackerone.com
Attacks that involve the user running malware that then places or modifies content on the target machine, which Steam could later run as the local user. However, any case that allows malware or compromised software to perform a privilege escalation through Steam, without providing administrative credentials or confirming a UAC dialog, is in scope. Any unauthorized modification of the privileged Steam Client Service is also in scope.
總結：雖然Valve之前對於提權漏洞的處理非常不負責任，但是鑒於他們現在承認了錯誤，我還是比較開心的。本次事件再次證明瞭，對於廠商錯誤忽略的漏洞，公開是最好的方法，這樣廠商迫於壓力也要迅速解決漏洞。如果當初Kravets沒有公開漏洞，修復遙遙無期。
客戶端的RCE漏洞一直都不少見，但是並不是都好利用，但 Steam 有自己的社區會導致這類攻擊變得可行，可傳播。
我在 ValveSoftware/steam-for-linux 給網頁版提過一個issue（當然和這個漏洞沒有關係），幾個月了沒人管，只加了個tag。翻一下還有人16年提的最近才close的。反饋效率低得可怕
推薦閱讀：
