Log for Ubuntu 台灣社群
#無關
想請問一下有朋友會安裝Kali 這個系統或是相關的社群嗎？
我卡在secure boot 那一關過不了
（Ubuntu 超成功）
我使用的是Rufus 製作image
所有系統、軟體、發行版皆為最新版本
想請問一下有朋友會安裝Kali 這個系統或是相關的社群嗎？
我卡在secure boot 那一關過不了
（Ubuntu 超成功）
我使用的是Rufus 製作image
所有系統、軟體、發行版皆為最新版本
我使用 o3 發現 Linux SMB 實作中的遠端零日漏洞 （★ 515 分 🔥）
在這篇技術部落格文章中，資安研究者 Sean Heelan 展示如何僅透過 OpenAI o3 模型就發現 Linux 核心中 ksmbd（在核心層實作 SMB3 協定，Server Message Block 檔案分享協定）的一個遠端零日弱點 CVE-2025-37899。Heelan 先以約 3.3k 行程式碼（27k tokens）的 session setup 路徑評估 CVE-2025-37778（金鑰驗證 Kerberos 認證流程中的 use-after-free 弱點），結果 o3 在 100 次測試中命中 8 次，並產生 28 次誤報。接著他將 o3 的輸入上下文擴大至包含所有 SMB2 指令處理器與連線建置／拆卸程式，共約 12k 行程式碼（100k tokens），雖然 Kerberos 認證弱點在此環境中僅命中 1 次，但 o3 同時意外挖掘出全新 session logoff 處理器的 use-after-free 問題：在處理多重綁定連線（SMB 3.0 以上）時，B 執行緒釋放並清空 `sess->user` 後，A 執行緒仍可存取該指標，導致核心記憶體損毀或服務當機。
文章認為，o3 代表了大型語言模型（LLM, Large Language Model）在程式推理能力上的重大躍進，對於少於 10k 行程式碼的弱點挖掘有合理成功率，且其輸出往往結構清晰、類似人類撰寫的漏洞報告；不過現階段仍有較高的雜訊比（signal-to-noise），需資安專家配合自動化篩選及概念驗證（Proof of Concept，PoC）機制，以確認可利用性並剔除誤報。Heelan 指出，LLM 不會取代專家，反而能顯著提升資安研究效率，值得在日常弱點掃描或程式碼審查流程中納入 o3。
在 Hacker News 的討論中，不少讀者好奇傳統核心模糊測試工具 syzkaller 是否能發現這兩個 use-after-free 弱點。有人指出，即使靜態分析或模糊測試可檢測一般記憶體安全問題，但面對需思考並發路徑、跨執行緒共用物件的缺陷時往往不易全面涵蓋，此時 LLM 能迅速掃描大量程式碼並提出潛在路徑，可與模糊測試及記憶體追蹤工具（如 KASAN）結合，加速驗證與 PoC 開發。也有讀者建議將 LLM 應用於 commit 審核或 CI/CD 安全掃描，讓防禦者主動發掘尚未修補的弱點。
同時，社群關注 o3 在實驗中的 signal-to-noise 比約 1:50，需投入大量人工職能進行結果 triage；成本與能源消耗也是討論焦點——作者透露 100k tokens、100 次測試約花費 116 美元，並消耗相當於微波爐長時間運作的電力。與此同時，不少人認為就算如此，LLM 在挖掘複雜弱點時仍具效率優勢，並可透過工程化管理 .prompt 檔、導入 prompt 工程最佳化與專案化流程，減少不必要的誤報、提升整體準確度。
最後，多位讀者預見，LLM 在資安攻防將引發新一輪武器化競賽：攻擊者可自動掃描龐大程式庫挖掘零日，而防禦者也必須擁抱相同技術，將自動化安全巡檢納入軟體開發生命週期。為了避免大量理論性但不可利用的漏洞報告氾濫，社群呼籲在 LLM 輔助的弱點研究中，務必結合 PoC、模糊測試與自動化驗證機制，確保每一項發現都經過實際可利用性的驗證，才能真正提升軟體安全防護水準。
👥 153 則討論、評論 💬
https://news.ycombinator.com/item?id=44081338
在這篇技術部落格文章中，資安研究者 Sean Heelan 展示如何僅透過 OpenAI o3 模型就發現 Linux 核心中 ksmbd（在核心層實作 SMB3 協定，Server Message Block 檔案分享協定）的一個遠端零日弱點 CVE-2025-37899。Heelan 先以約 3.3k 行程式碼（27k tokens）的 session setup 路徑評估 CVE-2025-37778（金鑰驗證 Kerberos 認證流程中的 use-after-free 弱點），結果 o3 在 100 次測試中命中 8 次，並產生 28 次誤報。接著他將 o3 的輸入上下文擴大至包含所有 SMB2 指令處理器與連線建置／拆卸程式，共約 12k 行程式碼（100k tokens），雖然 Kerberos 認證弱點在此環境中僅命中 1 次，但 o3 同時意外挖掘出全新 session logoff 處理器的 use-after-free 問題：在處理多重綁定連線（SMB 3.0 以上）時，B 執行緒釋放並清空 `sess->user` 後，A 執行緒仍可存取該指標，導致核心記憶體損毀或服務當機。
文章認為，o3 代表了大型語言模型（LLM, Large Language Model）在程式推理能力上的重大躍進，對於少於 10k 行程式碼的弱點挖掘有合理成功率，且其輸出往往結構清晰、類似人類撰寫的漏洞報告；不過現階段仍有較高的雜訊比（signal-to-noise），需資安專家配合自動化篩選及概念驗證（Proof of Concept，PoC）機制，以確認可利用性並剔除誤報。Heelan 指出，LLM 不會取代專家，反而能顯著提升資安研究效率，值得在日常弱點掃描或程式碼審查流程中納入 o3。
在 Hacker News 的討論中，不少讀者好奇傳統核心模糊測試工具 syzkaller 是否能發現這兩個 use-after-free 弱點。有人指出，即使靜態分析或模糊測試可檢測一般記憶體安全問題，但面對需思考並發路徑、跨執行緒共用物件的缺陷時往往不易全面涵蓋，此時 LLM 能迅速掃描大量程式碼並提出潛在路徑，可與模糊測試及記憶體追蹤工具（如 KASAN）結合，加速驗證與 PoC 開發。也有讀者建議將 LLM 應用於 commit 審核或 CI/CD 安全掃描，讓防禦者主動發掘尚未修補的弱點。
同時，社群關注 o3 在實驗中的 signal-to-noise 比約 1:50，需投入大量人工職能進行結果 triage；成本與能源消耗也是討論焦點——作者透露 100k tokens、100 次測試約花費 116 美元，並消耗相當於微波爐長時間運作的電力。與此同時，不少人認為就算如此，LLM 在挖掘複雜弱點時仍具效率優勢，並可透過工程化管理 .prompt 檔、導入 prompt 工程最佳化與專案化流程，減少不必要的誤報、提升整體準確度。
最後，多位讀者預見，LLM 在資安攻防將引發新一輪武器化競賽：攻擊者可自動掃描龐大程式庫挖掘零日，而防禦者也必須擁抱相同技術，將自動化安全巡檢納入軟體開發生命週期。為了避免大量理論性但不可利用的漏洞報告氾濫，社群呼籲在 LLM 輔助的弱點研究中，務必結合 PoC、模糊測試與自動化驗證機制，確保每一項發現都經過實際可利用性的驗證，才能真正提升軟體安全防護水準。
👥 153 則討論、評論 💬
https://news.ycombinator.com/item?id=44081338