CVE-2018-1058的處理策略

@fa[exclamation-triangle]保護好你的搜尋路徑

@fa[creative-commons]本簡報由 PostgreSQL.TW 提供

A Guide to CVE-2018-1058: Protect Your Search Path

• 可直接參閱 PostgreSQL wiki 說明內容
• 本簡報依據該文件內容製作而成

什麼是 CVE-2018-1058

CVE-2018-1058 描述了使用者如何在不同 schema 下建立類似名稱的物件，這些方式可以改變其他使用者查詢的行為並導致意外或惡意行為，也稱為「特洛伊木馬」攻擊。

↓

+++

簡而言之，透過 schema 搜尋路徑設定上的不嚴謹，產生惡意行為的風險。

例如：

SELECT * FROM table_a;

等同於

SELECT * FROM public.table_a;

↓

+++

舉例來說，如果 SESSION_USER 是 alice：

CREATE TABLE alice.a AS SELECT 1::int AS id;
CREATE TABLE public.a AS SELECT 'a'::text AS id;

接下來如果 alice 執行：

SELECT * FROM a;

那麼她會得到：

  id 
----
  1

也就是得到 alice.a 的內容。

那 CVE-2018-1058 的問題在哪裡呢？

關鍵在於「public」這個 schema，惡意的使用者可以利用 @fa[book]search_path 的設定，來改變其他使用者的行為。

↓ +++

試著混淆 search_path

假設有兩個使用者 alice 和 bob，使用同一個資料庫，也具備 public schema 建立的權限（一般預設的權限）：

CREATE TABLE a (full_name varchar(255));

他們都可能可以使用下面語法來查詢，來取得小寫的字串結果：

SELECT lower(full_name) FROM a;

↓ +++

可以建立另一個「lower」

CREATE FUNCTION lower(varchar) RETURNS text AS $$
    SELECT 'ALICE WAS HERE: ' || $1;
$$ LANGUAGE SQL IMMUTABLE;

而 bob 呼叫時：

SELECT lower(full_name) FROM a;

會發現 alice 成功地植入了「特洛伊木馬」！

那我的 PostgreSQL 也有這個問題嗎？

• 可能會有，但還不致於有立即性的危險。
• 這個問題在所有的 PostgreSQL 都有可能產生，如果你的情況不在下面所列的話：   1. 你總是使用 schema.object 完整路徑的呼叫方式。例如：SELECT pg_catalog.lower(‘ALICE’)   2. 你的資料庫規畫是單一使用者，並且資料庫上的使用者是可以信任的。   3. 你已經進行過下面一頁的步驟。

↓ +++

別讓你的使用者在 public 建立物件

REVOKE CREATE ON SCHEMA public FROM PUBLIC;

這樣就可以避免你的資料庫遭遇 CVE-2018-1058 的風險了。

你可以從 psql 這樣來看看 public 有哪些東西：

\df public.*

↓

+++

進一步明確化搜尋路徑

ALTER ROLE username SET search_path = "$user";

讓使用者一定是先搜尋同名 schema 下的物件。

↓

+++

在 postgresql.conf 中設定

search_path = '"$user"'

預設值可能會有 public，你可以把它刪去。

更多資訊還是到 wiki 看看吧！

PostgreSQL.TW