小巧、快速、可靠。
選擇其中三項。
弱點

1. 執行摘要

2. 關於 CVE

CVE(「常見漏洞和暴露」)是關於可能允許系統被駭客入侵的軟體錯誤的報告。CVE 背後的理念是合理的。它們提供了一個通用的命名方案,藉此可以輕鬆追蹤可能危及資訊安全的軟體錯誤。

雖然 CVE 的原始構想很合理,但目前建立和管理 CVE 的流程卻不足。有無數的灰帽駭客針對各種開源軟體產品(包括 SQLite 和許多其他產品)運行模糊測試器,並針對他們發現的任何問題撰寫 CVE。這些灰帽駭客會因其撰寫的 CVE 的數量和嚴重程度而獲得獎勵,有時是聲望,有時是金錢。這種誘因導致 CVE 的數量激增,而這些 CVE 通常未經充分審查,並且可能誇大其影響。CVE 的品質控管程序無法應付如此大量的輸入,因此難以糾正誇大、誤導、遺漏或不準確的聲稱。

這並不是說 CVE 毫無用處。CVE 確實(大多數情況下)會報告實際的錯誤。但在大多數情況下,這些錯誤並不是真正的漏洞,因為它們本身並不會導致資料遺失或洩漏。錯誤被報告並修復是件好事。但並非每個應用程式都能觸及每個錯誤。就 SQLite 而言,大多數 CVE 報告的錯誤在大部分應用程式中都無法觸及。升級到最新版本的 SQLite 總是個好主意,但僅僅因為網路上一個匿名的灰帽駭客寫了一個 CVE 就緊急升級則大可不必。

2.1. 通常需要另外的 SQL 注入漏洞

其他處理複雜結構化輸入的 C 函式庫通常會被要求處理來自不受信任來源的未經審查的輸入。像 libjpeg、libzip 或 OpenSSL 等函式庫會被傳遞直接來自潛在惡意代理的輸入串流。

但像 SQLite 這樣的資料庫引擎通常不是這樣運作的。傳遞到 SQLite 的 SQL 指令碼來自(受信任的)應用程式本身,而不是來自攻擊者。有時應用程式中存在錯誤,外部攻擊者可以藉此誘騙應用程式將攻擊者設計的 SQL 傳送到資料庫引擎。這是應用程式中的一個獨立錯誤,稱為SQL 注入漏洞。由於 SQL 文字是可執行程式碼,因此 SQL 注入漏洞實際上是遠端程式碼執行 (RCE) 漏洞的一個特例。SQL 注入也許不像其他類型的 RCE 那麼嚴重,因為雖然 SQL 是一種功能強大的語言,但它不像 Python、shell 指令碼或原始機器碼那樣便於製作漏洞攻擊。儘管如此,SQL 注入仍然是一個嚴重的問題。

大多數關於 SQLite 的 CVE 都假設攻擊者能夠在 SQLite 中執行任意 SQL 指令碼。在大多數應用程式中,這意味著首先必須存在一個 SQL 注入漏洞,允許攻擊者注入惡意 SQL。

少數應用程式確實允許在 SQLite 中直接執行從潛在惡意代理接收的不受信任的 SQL 指令碼。主要的例子是 Chrome 和 Safari 網頁瀏覽器,它們允許匿名網頁使用 Javascript 的 WebSQL 功能執行 SQL。這是透過對資源進行嚴格控制的沙盒來完成的,以免 SQL 指令碼試圖在阻斷服務攻擊中佔用所有可用的記憶體或 CPU 週期。Chrome 和 Safari 具有允許惡意代理執行不會損害或危害機器其餘部分的程式碼的基礎設施。它們必須如此,因為它們也執行 Javascript,如果沒有嚴格控制,Javascript 可能會造成比不受限制的 SQL 更大的損害。除了 Chrome 和 Safari 之外,據 SQLite 開發人員所知,沒有應用程式會故意允許匿名遠端代理執行任意 SQL 文字。

然而,大多數針對 SQLite 撰寫的 CVE 都輕率地假設攻擊者可以自由地在資料庫引擎中執行任何任意 SQL。因此,大致上來說,這意味著大多數針對 SQLite 撰寫的 CVE 實際上只適用於在 Chrome 和 Safari 中使用的 SQLite。換句話說,大多數針對 SQLite 的 CVE 對您並不適用,除非您是 Chrome 或 Safari 的開發人員之一。

2.2. 防禦黑暗魔法

大多數應用程式都可以使用 SQLite,而不必擔心隱晦 SQL 輸入中的錯誤。如果應用程式控制 SQL,且應用程式並非刻意嘗試破壞 SQLite,那麼一切應該都能正常運作。不需要使用最新修補版本的 SQLite。任何舊版本都應該可以正常運作。

然而,在某些情況下,應用程式確實需要能夠安全地執行不受信任的 SQL。SQLite 開發人員努力使 SQLite 在這種情況下安全,但偶爾還是會出現疏忽。在這種情況下,最好能隨時更新最新的修補程式。另外的防禦黑暗技藝文件包含了額外的建議,可以幫助防止零時差攻擊,以防 SQLite 接收來自不受信任來源的輸入。

2.3. SQLite 開發人員對 CVE 的政策

SQLite 開發人員會在錯誤回報後立即修復 SQLite 中的所有錯誤,通常在幾個小時內即可完成。修復程式會立即在公開的 SQLite 原始碼樹中提供。如果某個錯誤看起來可能會對現有的應用程式造成問題,就會發布 SQLite 的新修補程式版本。

然而,SQLite 開發人員並不追蹤 CVE。這有幾個原因:

  1. 開發人員通常是在錯誤修復很久之後才知道 CVE 的存在。您可以從許多 CVE 在其初始報告中引用錯誤修復的這個事實看出這一點。

  2. CVE 是關於 SQLite 中可能影響大多數應用程式的錯誤的低品質資訊來源。

  3. 幾乎所有 CVE 回報的錯誤都只是錯誤,而不是真正的漏洞。聲稱它們是漏洞,是擴大了「漏洞」一詞的含義,而 SQLite 開發人員不希望參與這種欺騙。

  4. 開發人員對 CVE 的內容沒有編輯影響力,他們不喜歡被沒有發言權的團體控制。

3. 近期 SQLite CVE 的狀態

雖然 SQLite 開發人員不認為 CVE 是關於 SQLite 錯誤的可靠資訊來源,但他們認識到許多團體,尤其是大型官僚機構底層的小型團隊,有時需要追蹤 CVE,無論它們是否有用。為了協助完成這項工作,我們提供了以下近期影響 SQLite 的 CVE 表格。

如果您發現與 SQLite 相關的新 CVE 未列在下表中,請在SQLite 論壇上告知開發人員,以便將其新增進去。

CVE 編號 修復 備註
CVE-2024-0232 3.43.2
(2023-10-10)
能夠將任意 SQL 陳述式注入應用程式的攻擊者可能會在 SQLite 的 JSON 解析器中觸發使用後釋放的錯誤,這(理論上)可能導致應用程式崩潰和服務阻斷。請參閱論壇主題 b25edc1d4662的錯誤報告。
CVE-2023-32697 非 SQLite 的錯誤 這是 SQLite JDBC 函式庫中的錯誤,該函式庫是一個包裝函式庫,提供從 Java 存取 SQLite 的功能。SQLite JDBC 是獨立於 SQLite 建立和維護的。儘管名稱中使用了「SQLite」,但 SQLite JDBC 函式庫與 SQLite 專案没有任何關係。此 CVE 識別的漏洞位於獨立的 SQLite JDBC 包裝函式庫中,不會影響 SQLite 本身。
CVE-2023-39939 非 SQLite 的錯誤 這不是 SQLite 的錯誤。這是連結到 SQLite 的應用程式 (LuxCal Web Calendar) 中的SQL 注入錯誤。即使此 CVE 與 SQLite 無關,說明中也提到了「SQLite」,因此我們在此列出。
CVE-2023-39543 非 SQLite 的錯誤 這並不是 SQLite 的錯誤,而是在連結 SQLite 的另一個應用程式 (LuxCal 網頁日曆) 中的跨網站指令碼 (XSS) 漏洞。 錯誤在應用程式中,而不是在 SQLite 中。 然而,由於說明中提到了「SQLite」,因此我們在此列出它。
CVE-2023-7104 3.43.1
(2023-09-11)
這是 SQLite session extension 中的錯誤,而不是 SQLite 核心中的錯誤。 只有使用 -DSQLITE_ENABLE_SESSION 編譯時選項重新編譯 SQLite,然後使用 Session C 語言 API 處理被攻擊者巧妙破壞的 變更集 的應用程式才能觸及此錯誤。 因此,此錯誤可能不適用於您。 請參閱 論壇文章 f935c4708dd528d9 以取得更多資訊。
CVE-2022-46908 不是核心 SQLite 函式庫中的錯誤 這是用於存取 SQLite 資料庫檔案的 命令列 shell 程式之 --safe 命令列選項中的錯誤。 這個錯誤不存在於 SQLite 函式庫中。 只要使用者不依賴 --safe 選項,CLI 也不會出現此問題。 這不是一個嚴重的問題。 這是否是一個安全問題還有待商榷。
CVE-2022-38627 非 SQLite 的錯誤 這並不是 SQLite 的錯誤,而是在特定 PHP 應用程式中的 SQL 注入錯誤。 換句話說,錯誤在 PHP 應用程式程式碼中,而不是在 SQLite 中。 儘管此 CVE 與 SQLite 無關,但在關於此錯誤的公開資訊中提到了「SQLite」,因此我們在此列出它。
CVE-2022-35737 3.39.2
(2022-07-21)
此錯誤是陣列邊界溢位。 只有在使用 SQLite 提供的一些 C 語言 API 時才能觸及此錯誤。 使用 SQL 或提供損毀的資料庫檔案給 SQLite 都無法觸及此錯誤。 只有在將非常長的字串輸入(長度超過 20 億位元組)作為參數提供給少數特定的 C 語言介面時,而且即使如此,也只有在特殊情況下才會出現此錯誤。
CVE-2022-24854 非 SQLite 的錯誤 此 CVE 描述的是使用 SQLite 的應用程式中的錯誤,而不是 SQLite 本身的錯誤。 SQLite 的所有操作都是正確的。 該應用程式授予使用者執行 SQL 陳述式(使用 SQLite)的能力,這些陳述式可能會洩漏或更改這些使用者通常不應存取的資訊。 這純粹是應用程式錯誤。 它並沒有描述 SQLite 中的故障或漏洞。
CVE-2022-21227 非 SQLite 的錯誤 此 CVE 描述的是第三方套件中的錯誤,該套件提供 SQLite 與 Node.js 的繫結。 報告的錯誤位於第三方 Node.js 繫結中,而不是 SQLite 本身。 不要被 CVE 描述中模稜兩可的「SQLite」一詞所混淆。
CVE-2021-45346 非 SQLite 的錯誤 此 CVE 是錯誤資訊。 請參閱 SQLite 論壇文章 53de8864ba114bf 周圍的討論。
CVE-2021-42169 非 SQLite 的錯誤 此 CVE 與 SQLite 完全無關。 它是關於一個恰好使用 SQLite 的應用程式中的錯誤。 由於 CVE 描述中提到了 SQLite,因此在此包含此 CVE 以強調這不是 SQLite 錯誤。
CVE-2021-36690 不是核心 SQLite 函式庫中的錯誤 此錯誤不在 SQLite 核心函式庫中,而是在用於實作 CLI.expert 命令實驗性擴充功能中。 包含此錯誤的程式碼並未出現在標準 SQLite 組建中,但它包含在 sqlite3.exe 命令列工具中。 應用程式必須連結到實作該擴充功能的額外原始程式碼檔案,並採取其他刻意動作來啟動該擴充功能,才能執行有問題的程式碼。 對於少數使用有問題擴充功能的應用程式,此錯誤的後果是惡意 SQL 可能導致 NULL 指標解參考和服務阻斷。 (詳細資訊)
CVE-2021-28305 非 SQLite 的錯誤 這並非 SQLite 本身的錯誤,而是使用 SQLite 的第三方應用程式出現錯誤。雖然 CVE 描述中提到了 SQLite 的名稱,但我們還是將此 CVE 列入清單中。
CVE-2021-23404 非 SQLite 的錯誤 這並非 SQLite 的錯誤,而是使用 SQLite 並且名稱中包含「sqlite」的第三方應用程式出現錯誤。儘管此錯誤與 SQLite 無關,但由於 CVE 描述中提到了 SQLite,因此我們將其列入清單中。
CVE-2021-20227 3.34.1
(2021-01-20)
惡意 SQL 陳述式導致釋放後使用 (read-after-free) 錯誤。據目前所知,此特定的釋放後使用案例不會造成任何損害。沒有記憶體偵錯工具則無法偵測到此錯誤。CVE 聲稱此錯誤是一個 RCE(遠端程式碼執行)漏洞,但此說法並不正確。RCE 的說法是錯誤資訊。(詳細資訊)
CVE-2021-20223 3.34.0
(2020-12-01)
此 CVE 所指出的問題並非漏洞,而是一個故障。程式碼錯誤導致 FTS5 在某些特殊情況下有時會傳回不一致且不正確的結果,但不會發生記憶體錯誤。(詳細資訊)
CVE-2020-15358 3.32.3
(2020-06-18)
惡意 SQL 陳述式導致讀取超出堆積緩衝區的末尾。(詳細資訊)
CVE-2020-13871 3.32.3
(2020-06-18)
惡意 SQL 陳述式導致唯讀的釋放後使用記憶體錯誤。(詳細資訊)
CVE-2020-13632 3.32.0
(2020-05-22)
惡意 SQL 陳述式導致在 FTS3 擴充功能的 matchinfo() SQL 函式中讀取空指標,導致阻斷服務。(詳細資訊)
CVE-2020-13631 3.32.0
(2020-05-22)
惡意 SQL 陳述式(嘗試將虛擬表格重新命名為其自身的陰影表格的 ALTER TABLE 陳述式)導致無限迴圈和阻斷服務。(詳細資訊)
CVE-2020-13630 3.32.0
(2020-05-22)
惡意 SQL 陳述式導致唯讀的釋放後使用錯誤,可能導致 FTS3 擴充功能的 snippet() SQL 函式輸出不正確的結果。目前尚無已知方法可以利用此錯誤竊取資料或使應用程式崩潰。(詳細資訊)
CVE-2020-13435 3.32.1
(2020-05-25)
惡意 SQL 陳述式導致讀取空指標並造成阻斷服務。(詳細資訊)
CVE-2020-13434 3.32.1
(2020-05-25)
涉及 printf() SQL 函式的惡意 SQL 陳述式會導致整數溢位,進而可能使用超過 20 億位元組的 0x30 或 0x20(ASCII '0' 或 ' ')覆蓋堆疊。即使這是堆疊覆蓋,也沒有已知的方法可以重新導向控制或進一步提升危害程度。這僅為阻斷服務攻擊。(詳細資訊)
CVE-2020-11656 3.32.0
(2020-05-22)
如果使用 -DSQLITE_DEBUG 編譯 SQLite,惡意 SQL 陳述式會導致唯讀的記憶體配置釋放後使用錯誤。不影響正式版本。(詳細資訊)
CVE-2020-11655 3.32.0
(2020-05-22)
惡意 SQL 陳述式導致使用未初始化的指標進行讀取,並造成阻斷服務。(詳細資訊)
CVE-2020-9327 3.32.0
(2020-05-22)
惡意 SQL 陳述式導致使用未初始化的指標進行讀取,並造成阻斷服務。(詳細資訊)
CVE-2020-6405 3.31.0
(2020-01-22)
惡意 SQL 陳述式導致空指標解除參照,並造成阻斷服務。(詳細資訊)
CVE-2019-20218 3.31.0
(2020-01-22)
惡意 SQL 陳述式導致讀取未初始化的指標,並造成阻斷服務。(詳細資訊)
CVE-2019-19959 3.31.0
(2020-01-22)
惡意 SQL 陳述式導致在 Zipfile 虛擬表格擴充功能中解除參照空指標,並造成阻斷服務。僅在部署選用的 Zipfile 虛擬表格擴充功能時才會發生此情況,預設建置中不會發生此情況。(詳細資訊)
CVE-2019-19926 3.31.0
(2020-01-22)
惡意 SQL 陳述式會造成未初始化的指標讀取並導致阻斷服務。 (詳細資訊)
CVE-2019-19925 3.31.0
(2020-01-22)
惡意 SQL 陳述式會在 Zipfile 虛擬表格 擴充功能中造成空指標解參考並導致阻斷服務。 只有在部署了選用的 Zipfile 虛擬表格 擴充功能時才會發生這種情況,預設建置中並不會發生。 (詳細資訊)
CVE-2019-19924 3.31.0
(2020-01-22)
惡意 SQL 陳述式會造成未初始化的指標參考並導致阻斷服務。 (詳細資訊)
CVE-2019-19923 3.31.0
(2020-01-22)
惡意 SQL 陳述式會造成空指標解參考並導致阻斷服務。 (詳細資訊)
CVE-2019-19646 3.31.0
(2020-01-22)
PRAGMA integrity_check 指令可能會導致已準備好的陳述式的位元組碼無限迴圈。 如果應用程式沒有採取適當且謹慎的步驟來限制 SQL 陳述式的執行時間,則可能會導致阻斷服務。 這並不是一個漏洞,因為有無數完全有效的 SQL 查詢,尤其是涉及 遞迴通用表表達式 的查詢,它們基本上也會永遠執行。 (詳細資訊)
CVE-2019-19317 3.31.0
(2020-01-22)
此 CVE 指出 SQLite 開發簽入版本中的一個錯誤。 該錯誤從未出現在任何正式發布的 SQLite 版本中。 (詳細資訊)