PostgreSQL 設計缺陷可導致許可權提升

長 亭 漏 洞 預 警

PostgreSQL設計缺陷可導致許可權提升

2018年3月1日，PostgreSQL全球開發團隊發布了多個系列版本的PostgreSQL安全升級。此次升級修復了CVE-2018-1058，攻擊者可利用該漏洞「劫持」PostgreSQL資料庫的函數，從而使高許可權用戶在不知情的情況下，執行攻擊者設定的惡意SQL語句。

漏洞成因

想要理解此漏洞需要先了解PostgreSQL兩方面的設計。

schemas

PostgreSQL自7.3版本以後允許用戶在資料庫中創建一類命名空間schemas，允許多用戶使用同一資料庫而不會互相影響，讓資料庫里的對象從邏輯上更易於管理。當用戶創建資料庫後，默認操作設置都是在名為「public」的schema下進行的。例如SELECT * FROM Infomation;實際上等於SELECT * FROM public.Infomation;

在默認情況下，任何用戶可以在public下創建對象(新建表、新建函數等操作)。

search_path 搜索順序

因為PostgreSQL提供了schemas這個功能，假如用戶新建了一個schema叫做private，在此schema中新建了一個和public中的同名表Information。

當用戶執行SELECT * FROM Information;沒有指定schema時，PostgreSQL就會根據下圖流程進行優先順序的判斷：

當PostgreSQL遇到按照順序遇到「最佳匹配」時，就會選擇該schema進行操作(其中$user為當前session用戶)。

漏洞利用場景

首先分別創建高低許可權用戶

administrator: 所有許可權

hacker: 只有對public的create許可權

目標：獲取只有administrator擁有許可權讀取的private schema表Information中的信息。

在用revoke命令去除hacker賬戶的對private schema 的SELECT許可權之後，hacker沒有許可權讀取到private.Information的數據。

攻擊者編寫如下惡意Postgresql函數:

CREATE FUNCTION upper(varchar) RETURNS text AS $$

ALTER ROLE hacker SUPERUSER;

SELECT pg_catalog.upper($1);

$$ LANGUAGE SQL VOLATILE;

模擬以administrator用戶打開另外一個SESSION，可以看見administrator能夠讀取private.Information下的敏感信息。

當administrator執行select upper((select * from private.Information));時，就會觸發hacker的惡意函數。

可以看到hacker許可權已經被修改為了SUPERUSER，並且private.Information里的內容也可以讀取了。

其中先執行了public.upper而沒有執行pg_catalog.upper的原因是這兩個函數所接受的參數類型不一樣。

對比：

pg_catalog.upper(text)

public.upper(varchar)

varchar與text兩種在Postgresql中屬於相似但不同的變數類型。

hacker編寫的upper函數接受的是varchar類型的參數，而pg_catalog中內置的系統函數接受的參數為text。所以惡意upper函數屬於「最佳匹配」，最終administrator會執行惡意upper()函數，導致SQL執行流程被篡改。

漏洞影響範圍

影響版本：

Redhat Satellite 5

PostgreSQL PostgreSQL 9.6.7

PostgreSQL PostgreSQL 9.6.4

PostgreSQL PostgreSQL 9.6

PostgreSQL PostgreSQL 9.5.11

PostgreSQL PostgreSQL 9.5.10

PostgreSQL PostgreSQL 9.5.9

PostgreSQL PostgreSQL 9.5.8

PostgreSQL PostgreSQL 9.5.7

PostgreSQL PostgreSQL 9.5.6

PostgreSQL PostgreSQL 9.5.4

PostgreSQL PostgreSQL 9.5.1

PostgreSQL PostgreSQL 9.5

PostgreSQL PostgreSQL 9.4.16

PostgreSQL PostgreSQL 9.4.15

PostgreSQL PostgreSQL 9.4.14

PostgreSQL PostgreSQL 9.4.13

PostgreSQL PostgreSQL 9.4.12

PostgreSQL PostgreSQL 9.4.11

PostgreSQL PostgreSQL 9.4.9

PostgreSQL PostgreSQL 9.4.6

PostgreSQL PostgreSQL 9.4.5

PostgreSQL PostgreSQL 9.4.4

PostgreSQL PostgreSQL 9.4.3

PostgreSQL PostgreSQL 9.4.2

PostgreSQL PostgreSQL 9.4.1

PostgreSQL PostgreSQL 9.4

PostgreSQL PostgreSQL 9.3.21

PostgreSQL PostgreSQL 9.3.20

PostgreSQL PostgreSQL 9.3.19

PostgreSQL PostgreSQL 9.3.18

PostgreSQL PostgreSQL 9.3.17

PostgreSQL PostgreSQL 9.3.16

PostgreSQL PostgreSQL 9.3.14

PostgreSQL PostgreSQL 9.3.11

PostgreSQL PostgreSQL 9.3.10

PostgreSQL PostgreSQL 9.3.9

PostgreSQL PostgreSQL 9.3.8

PostgreSQL PostgreSQL 9.3.7

PostgreSQL PostgreSQL 9.3.6

PostgreSQL PostgreSQL 9.3.5

PostgreSQL PostgreSQL 9.3.4

PostgreSQL PostgreSQL 9.3.3

PostgreSQL PostgreSQL 9.3.2

PostgreSQL PostgreSQL 9.3

PostgreSQL PostgreSQL 9.6.6

PostgreSQL PostgreSQL 9.6.3

PostgreSQL PostgreSQL 9.6.2

PostgreSQL PostgreSQL 9.6.1

PostgreSQL PostgreSQL 9.5.2

PostgreSQL PostgreSQL 9.4.1-1

PostgreSQL PostgreSQL 9.3.1

PostgreSQL PostgreSQL 10.0

未影響版本：PostgreSQL PostgreSQL 9.6.8

PostgreSQL PostgreSQL 9.5.12

PostgreSQL PostgreSQL 9.4.17

PostgreSQL PostgreSQL 9.3.22

PostgreSQL PostgreSQL 10.3

漏洞修復方案

官方修復建議：

1. 超級管理員可以移除所有用戶在public schema中創建對象的許可權：

REVOKE CREATE ON SCHEMA public FROM PUBLIC;

該操作會導致所有非超級用戶無法進行創建對象，可能影響用戶管理程序。

2. 檢測對比public中與pg_catalog是否有相似對象，防止已經被惡意篡改。

df public.*

df pg_catalog.*

3. 只設置用戶seach_path值為"$user"變數。

ALTER ROLE username SET search_path = "$user";

官方概括了整個防禦策略為：「Do not allow users to create new objects in the public schema」 strategy。

參考資料

https://wiki.postgresql.org/wiki/A_Guide_to_CVE-2018-1058:_Protect_Your_Search_Path

https://github.com/postgres/postgres/commit/5770172cb0c9df9e6ce27c507b449557e5b45124

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！