【資安小知識】Linux Kernel 出漏洞 Ubuntu 該升級哪一版?

因為去年底出的一個新的 Kernel 漏洞 CVE-2022-47939,要幫忙檢查 Ubuntu 有沒有需要更新 Kernel,所以就寫了這篇記錄一下。

首先,這個漏洞在 mitre 的 cve 頁面 中寫了影響的範圍是 Linux kernel 5.15 through 5.19 before 5.19.2,出問題的是 ksmbd 這個 kernel module,他是在 5.15 版本被引入的,所以 5.15 之前的版本就沒事,最後是在 這個 commit 中修掉的,這個 commit 的 message 是 ksmbd: fix use-after-free bug in smb2_tree_disconect,跟在 mitre 的 cve 的敘述中寫的一樣,在頁面下方的 References 其實也可以看到這個 commit 的連結。

所以我們知道有問題的 Linux Kernel 版本是什麼,但是我要怎麼在 Ubuntu 上面看我的 Linux Kernel 是幾版,上網查一下或是問 chatgpt,其實就可以得到這個指令 uname -r,執行這個指令之後,在我的機器上給出了 5.15.0-58-generic 這樣的版本號,看起來是 5.15 版本,是在有漏洞的範圍裡面,但其實並沒有,因為這是 Ubuntu 自己 build 的版本號,並不是 Linux Kernel 的版本號,Ubuntu 的版本號的命名慣例是 <base kernel version>-<ABI number>.<upload number>-<flavour>,你會發現把剛剛的 5.15.0-58-generic 套在這個格式上看好像少了一個 upload number,我們可以用 cat /proc/version_signature 查看比較詳細的版本號,在我的機器上的結果是 Ubuntu 5.15.0-58.64-generic 5.15.74,分別是

  • base kernel version: 5.15.0
  • ABI number: 58
  • upload number: 64
  • flavour: generic
  • upstream linux kernel: 5.15.74

最後他還多給了一個 upstream linux kernel 的版本號。ABI number 指的是 kernel 本身開出來的 application binary interface 介面的版本號,如果你把 kernel 看成是一個後端 server,那他就是指你的 REST API 的接口,所以可能會跟 upload number 不同,因為可能兩個不同的 kernel 版本只是修了些 bug,沒有開新的 api,或是 api 的參數沒有變化,這時候這個 ABI number 就不會變。而 upload number 單純就是一個流水號,指從這個 5.15.0 base kernel version 長出來的第幾個版本,所以我們可以看這個號碼來分辨前後順序。

Ubuntu Secuity: CVE-2022-47939 發布的漏洞公告中,我們可以看到他有列出他們上 patch 的版本,Ubuntu 22.04 (jammy) 的是 5.15.0-53.59,我們可以直接去看 Ubuntu linux source package 中 5.15.0-53.59 版本的 Changlog,這裡我們搜尋 smb2_tree_disconect 就可以找到在這個版本的更新有納入 v5.15.61 upstream linux kernel 其中修掉了這次的 CVE-2022-47939,而我的機器是 5.15.0-58.64,是在 5.15.0-53.59 後面的,所以其實我的機器的 Linux Kernel 已經有修補掉這個漏洞了。

總結來說,在 Ubuntu 下 uname -r 得到的版本號其實不能直接對應到 Linux Kernel 的版本號,Ubuntu 本身是從 Linux 分支出來的,所以自己有一個版本號,我們這次介紹了 Ubuntu 版本號各個欄位的意思,並且找到我們的版本號其實是已經有上 patch 了,這樣之後出新的漏洞就可以知道要升級到哪個版本可以修補掉漏洞。

Read more

【漏洞分析】CVE-2022-41049

11/08 Windows 的 Patch Tuesday 中修補了兩個關於 Bypass Mark-of-the-Web (MOTW) 的漏洞,分別是 CVE-2022-41049 和 CVE-2022-41091,在 Exploring ZIP Mark-of-the-Web Bypass Vulnerability (CVE-2022-41049) 這篇部落格中,有詳細的分析這個漏洞的細節,也是本篇部落格主要參考的來源

這個漏洞最早在 6 月在 twitter 上 Will Dormann 的貼文中 就有提及
並且在 10 月就有在野外觀察到這個漏洞被利用

Alternative Data Stream (ADS)

要解釋這個漏洞之前,要先說明一下什麼是 Alternative Data Stream (ADS)
ADS 是 NTFS 檔案系統的一個功能,允許一個檔案可以有多個 Stream,也就是雖然檔名是一樣的,但是透過不同的 Stream 可以存取到不同的資料
比如 test.txt 這個檔案可以有好幾種不同的 Stream

  • test.txt::$DATA
  • test.txt:Zone.Identifier
  • test.txt:Hello
  • test.txt:World

MOTW

瀏覽器會把從網路下載下來的檔案,新增一個 Zone.Identifier 的 Stream,這就是傳說中的 Mark-of-the-Web (MOTW)
我們可以用 Powershell 下指令 Get-Item <filename> -Stream * 來列出某個檔案的所有 Stream 如下圖所示

接著用 Get-Content <filename> -Stream Zone.Identifier 去印出 Zone.Identifier Stream 裡面的資料如下圖所示

可以看到 Zone.Identifier Stream 裡面存了 ZoneIdHostUrl 這些 metadata

那有 MOTW 的檔案可以做什麼?
有 MOTW 的檔案就等於給其他軟體們一個資訊,這個檔案是來自網路,像是 WORD, EXCEL, Visual Studio 等軟體以及 Windows 本身,在處理這些檔案的時候就會格外小心,並且對使用者發出額外的警告,像是如下圖的這些警告

CVE-2022-41049

背景知識都補充足夠了,那這個 CVE-2022-41049 的漏洞又是出了什麼問題
正常情況中,檔案總管 (Explorer) 在解壓縮 zip 的時候,會把 zip 檔案的 MOTW 複製到解壓縮出來的所有檔案上面
但是只要那個 zip 檔案是用某個特別的方法製作的時候,MOTW 就不會被傳遞下去,也就成功 Bypass MOTW

這個特別的製作方法,說起來也不是那麼特別,其實也是正常的 feature
只要你的檔案在壓縮的時候是 read-only 的
在解壓縮的時候,因為檔案是 read-only 的關係,所以檔案總管就無法去寫入 MOTW 到解壓縮出的檔案上面
就是這麼簡單,非常簡單就可以實作

這篇 Exploring ZIP Mark-of-the-Web Bypass Vulnerability (CVE-2022-41049) 部落格中,作者做了非常深入的調查,最後才發現只是這麼簡單的原因,原文分析的思路也推薦大家可以看看
除了 zip,其他的打包格式比如 iso, vhd, gzip 等,也是新的 bypass MOTW 的方法
整體來看,Mark-of-the-Web (MOTW) 其實不算是一個 Security Boundary,比較像是一個額外的警告功能,使用者在下載網路上的資源的時候還是要謹慎小心,多看幾眼xD


  1. https://breakdev.org/zip-motw-bug-analysis/
  2. https://www.ithome.com.tw/news/154096
Read more