Log for Ubuntu 台灣社群
Ubuntu 看起來已經可以更新了
USN-8281-1: Linux kernel vulnerabilities
https://ubuntu.com/security/notices/USN-8281-1
USN-8281-1: Linux kernel vulnerabilities
https://ubuntu.com/security/notices/USN-8281-1
Ubuntu 連 Copy Fail 到現在都只有 mitigation 而已，沒有 fix
Copy Fail mitigation 還包 deb 給你 apt 更，Dirty Frag 之後開始擺爛只給 manual mitigation，上週就爆的 ssh-keysign-pwn 別人 fix 都 release 了它 blog 剛剛才出來 🚬
Copy Fail mitigation 還包 deb 給你 apt 更，Dirty Frag 之後開始擺爛只給 manual mitigation，上週就爆的 ssh-keysign-pwn 別人 fix 都 release 了它 blog 剛剛才出來 🚬
GitHub 遭入侵 （★ 107 分）
GitHub 在 X 發文說明，已針對內部儲存庫遭未經授權存取的事件公布更多調查細節。GitHub 表示，前一天偵測並控制了一起員工裝置遭入侵的情況，攻擊途徑是一個遭投毒的 VS Code（Visual Studio Code，微軟開發的程式編輯器）擴充套件。GitHub 已移除該擴充套件的惡意版本、隔離受影響端點裝置，並立即啟動資安事件應變流程。
這起事件被討論的核心在於開發工具供應鏈攻擊（攻擊開發工具、套件或散布管道，間接入侵目標）的風險：即使主要平台本身未必是第一個被攻破的目標，開發者日常使用的編輯器擴充套件仍可能成為進入企業內部環境的跳板。討論串中也反覆提到約 3,800 個內部儲存庫暴露的說法，引發外界關注單一員工帳號或裝置為何可能觸及如此大範圍的內部程式碼。
Hacker News 討論中，許多工程背景留言認為，大型科技公司讓工程師對大量非敏感程式碼具備唯讀權限並不罕見，因為跨團隊除錯、理解系統架構、避免重複開發，都需要查閱其他團隊的儲存庫；以 GitHub 的規模，累積數千個內部儲存庫也不令人意外。不過也有人質疑，若一名員工可讀取過多內部資產，代表最小權限原則（least privilege，只給工作所需最低權限）落實不足，攻擊者一旦取得該員工環境，就能大幅擴大影響範圍。
另一個主要觀點是，企業內部權限管理常在安全與生產力之間拉扯。有人主張應採用即時授權（JIT, just-in-time access）模式：工程師需要資源時可快速申請，多數低風險情境自動核准，未使用的權限自動到期，並搭配異常偵測、稽核與必要時升級審核；這比長期廣泛開放或繁瑣人工簽核都更合理。也有留言指出，若企業為了「快速移動」而給予過大內部權限，威脅行為者同樣能在入侵後快速橫向移動。
針對攻擊細節，討論中有人懷疑攻擊者是否真的下載了全部儲存庫，因為大量外傳資料理應觸發偵測；也有人補充，GitHub / Microsoft 內部環境可能使用 Git Credential Manager（Git 憑證管理工具）強制多因素驗證（MFA, multi-factor authentication），並可能搭配 VPN（虛擬私人網路）或 IP 位址限制，因此單純竊取 SSH key（用於加密登入的金鑰）未必足以複製所有內容。另有留言猜測惡意擴充套件可能與 NX Console 事件有關，但 GitHub 的貼文並未確認此點。整體而言，這起事件讓更多人主張企業除了限制 Docker Hub、PyPI（Python 套件索引）等外部套件來源，也應開始對 VS Code 擴充套件採取白名單與裝置管理控管。
👥 29 則討論、評論 💬
https://news.ycombinator.com/item?id=48202993
GitHub 在 X 發文說明，已針對內部儲存庫遭未經授權存取的事件公布更多調查細節。GitHub 表示，前一天偵測並控制了一起員工裝置遭入侵的情況，攻擊途徑是一個遭投毒的 VS Code（Visual Studio Code，微軟開發的程式編輯器）擴充套件。GitHub 已移除該擴充套件的惡意版本、隔離受影響端點裝置，並立即啟動資安事件應變流程。
這起事件被討論的核心在於開發工具供應鏈攻擊（攻擊開發工具、套件或散布管道，間接入侵目標）的風險：即使主要平台本身未必是第一個被攻破的目標，開發者日常使用的編輯器擴充套件仍可能成為進入企業內部環境的跳板。討論串中也反覆提到約 3,800 個內部儲存庫暴露的說法，引發外界關注單一員工帳號或裝置為何可能觸及如此大範圍的內部程式碼。
Hacker News 討論中，許多工程背景留言認為，大型科技公司讓工程師對大量非敏感程式碼具備唯讀權限並不罕見，因為跨團隊除錯、理解系統架構、避免重複開發，都需要查閱其他團隊的儲存庫；以 GitHub 的規模，累積數千個內部儲存庫也不令人意外。不過也有人質疑，若一名員工可讀取過多內部資產，代表最小權限原則（least privilege，只給工作所需最低權限）落實不足，攻擊者一旦取得該員工環境，就能大幅擴大影響範圍。
另一個主要觀點是，企業內部權限管理常在安全與生產力之間拉扯。有人主張應採用即時授權（JIT, just-in-time access）模式：工程師需要資源時可快速申請，多數低風險情境自動核准，未使用的權限自動到期，並搭配異常偵測、稽核與必要時升級審核；這比長期廣泛開放或繁瑣人工簽核都更合理。也有留言指出，若企業為了「快速移動」而給予過大內部權限，威脅行為者同樣能在入侵後快速橫向移動。
針對攻擊細節，討論中有人懷疑攻擊者是否真的下載了全部儲存庫，因為大量外傳資料理應觸發偵測；也有人補充，GitHub / Microsoft 內部環境可能使用 Git Credential Manager（Git 憑證管理工具）強制多因素驗證（MFA, multi-factor authentication），並可能搭配 VPN（虛擬私人網路）或 IP 位址限制，因此單純竊取 SSH key（用於加密登入的金鑰）未必足以複製所有內容。另有留言猜測惡意擴充套件可能與 NX Console 事件有關，但 GitHub 的貼文並未確認此點。整體而言，這起事件讓更多人主張企業除了限制 Docker Hub、PyPI（Python 套件索引）等外部套件來源，也應開始對 VS Code 擴充套件採取白名單與裝置管理控管。
👥 29 則討論、評論 💬
https://news.ycombinator.com/item?id=48202993
GitHub 內部程式碼儲存庫遭未授權存取 （★ 146 分）
GitHub 在 X（原 Twitter）公告，針對內部 repo（repository，程式碼儲存庫）遭未授權存取的調查，已確認事件源自一名員工裝置遭入侵，攻擊媒介是一個被植入惡意內容的 VS Code（Visual Studio Code，Microsoft 的程式碼編輯器）擴充套件。GitHub 表示已偵測並遏止事件，移除該擴充套件的惡意版本、隔離受影響端點（endpoint，受管理的連線裝置），並立即啟動資安事故應變流程。
這起事件的重點不只是 GitHub 內部程式碼遭讀取，也凸顯開發工具供應鏈攻擊的風險：開發者日常使用的編輯器擴充套件，一旦被污染，就可能成為進入企業內部環境的入口。公開貼文中可見的說法聚焦於「內部 repo」與員工端點，並未顯示客戶私有 repo 遭存取的官方說明。
Hacker News（科技新聞討論站）上的討論則集中在傳出約 3,800 個內部 repo 曝光的規模，以及為何單一開發者帳號會擁有如此廣泛的唯讀權限。部分人認為，大型工程組織讓開發者讀取多數非敏感程式碼很常見，能降低跨團隊協作摩擦、協助理解系統架構，也避免每次都要申請權限；以 GitHub 的規模來看，數千個 repo 可能包含測試、工具、微服務、fork 與原型，並不必然異常。另一派則認為，即使只是唯讀，一台員工裝置遭攻破就可能擴大外洩範圍，顯示最小權限原則落實不足。
不少留言主張，企業需要在生產力與風險控管之間採取更細緻的做法，例如 JIT（Just-in-Time，臨時按需）存取、權限自動到期、異常行為偵測與稽核，而不是讓所有開發者長期持有大範圍權限。也有人討論攻擊者是否只需竊取 SSH 金鑰（用於登入或驗證的憑證）即可大量 clone 程式碼；其他人補充，Microsoft 與 GitHub 內部可能不允許 SSH key 直接用於這類存取，而是透過 git-credential-manager 與 MFA（Multi-Factor Authentication，多因素驗證）等機制，也可能搭配 VPN（Virtual Private Network，虛擬私人網路）或 IP 限制。
對於被污染的 VS Code 擴充套件，社群批評 GitHub 未立即明確點名來源，也有人猜測可能與 NX Console 的安全公告有關，但這類說法需以官方確認為準。更廣泛的共識是，企業過去常限制 Docker Hub（容器映像檔倉庫）、PyPI（Python Package Index，Python 套件庫）或 npm（JavaScript 套件庫）的使用，未來可能也必須對 VS Code 擴充套件建立可信清單與審查流程。即使許多人認為「程式碼外流」不等於系統立即失守，這起事件仍凸顯第三方開發工具、員工端點與廣泛讀取權限疊加後，會大幅放大資安事故的影響範圍。
👥 43 則討論、評論 💬
https://news.ycombinator.com/item?id=48202993
GitHub 在 X（原 Twitter）公告，針對內部 repo（repository，程式碼儲存庫）遭未授權存取的調查，已確認事件源自一名員工裝置遭入侵，攻擊媒介是一個被植入惡意內容的 VS Code（Visual Studio Code，Microsoft 的程式碼編輯器）擴充套件。GitHub 表示已偵測並遏止事件，移除該擴充套件的惡意版本、隔離受影響端點（endpoint，受管理的連線裝置），並立即啟動資安事故應變流程。
這起事件的重點不只是 GitHub 內部程式碼遭讀取，也凸顯開發工具供應鏈攻擊的風險：開發者日常使用的編輯器擴充套件，一旦被污染，就可能成為進入企業內部環境的入口。公開貼文中可見的說法聚焦於「內部 repo」與員工端點，並未顯示客戶私有 repo 遭存取的官方說明。
Hacker News（科技新聞討論站）上的討論則集中在傳出約 3,800 個內部 repo 曝光的規模，以及為何單一開發者帳號會擁有如此廣泛的唯讀權限。部分人認為，大型工程組織讓開發者讀取多數非敏感程式碼很常見，能降低跨團隊協作摩擦、協助理解系統架構，也避免每次都要申請權限；以 GitHub 的規模來看，數千個 repo 可能包含測試、工具、微服務、fork 與原型，並不必然異常。另一派則認為，即使只是唯讀，一台員工裝置遭攻破就可能擴大外洩範圍，顯示最小權限原則落實不足。
不少留言主張，企業需要在生產力與風險控管之間採取更細緻的做法，例如 JIT（Just-in-Time，臨時按需）存取、權限自動到期、異常行為偵測與稽核，而不是讓所有開發者長期持有大範圍權限。也有人討論攻擊者是否只需竊取 SSH 金鑰（用於登入或驗證的憑證）即可大量 clone 程式碼；其他人補充，Microsoft 與 GitHub 內部可能不允許 SSH key 直接用於這類存取，而是透過 git-credential-manager 與 MFA（Multi-Factor Authentication，多因素驗證）等機制，也可能搭配 VPN（Virtual Private Network，虛擬私人網路）或 IP 限制。
對於被污染的 VS Code 擴充套件，社群批評 GitHub 未立即明確點名來源，也有人猜測可能與 NX Console 的安全公告有關，但這類說法需以官方確認為準。更廣泛的共識是，企業過去常限制 Docker Hub（容器映像檔倉庫）、PyPI（Python Package Index，Python 套件庫）或 npm（JavaScript 套件庫）的使用，未來可能也必須對 VS Code 擴充套件建立可信清單與審查流程。即使許多人認為「程式碼外流」不等於系統立即失守，這起事件仍凸顯第三方開發工具、員工端點與廣泛讀取權限疊加後，會大幅放大資安事故的影響範圍。
👥 43 則討論、評論 💬
https://news.ycombinator.com/item?id=48202993