2007-05-12

【PostgreSQL观察】第36回 PostgreSQL的安全补丁(一)(简体)

更新:2007-05-12
對映章節:
http://itpro.nikkeibp.co.jp/article/COLUMN/20070507/270174/

翻译自石井达夫先生的文章

新的安全漏洞
在PostgreSQL观察第35回,传达了来自核心开发成员的安全补丁发表预告以及关于SECURITY DEFINER函数(可以使用其他用户权限的函数)的安全警告,这次新发现的安全漏洞正是与SECURITY DEFINER有关。

SCHAMA搜索路径(search path)的问题
在讨论本次发现的安全漏洞之前,我们先复习一下上回提到的“安全警告”,他们的根源是一样的。
PostgreSQL中有Schema的概念,也就是命名空间,在不同的schema中可以创建名字相同的数据表,这就像在UNIX中可以在不同目录下创建同名文件一样。它有两种用法:
一种是显式指定schema名:public.t1指定public schema下的t1对象。
另一种方法是 使用schema search path,指定当省略schema名称的时候,优先使用哪一个schema。可以用“show search_path”命令来确认当前的 schema search path:
test=> show search_path;
search_path
----------------
"$user",public
(1 row)
这个例子显示以当前登陆用户名为第一优先schema名称,然后是名为public的schema。顺便提一下public这个特殊schema,它是缺省的schema,如果什么也不指定的话,对象将被建立在public中。

利用pg_catalog schema的攻击
除此之外还有持有系统catalog、聚集函数(aggregate)、操作符(operator)的pg_catalog schema,即使它没有包含在搜索路径中一般也被当作搜索对象,并经常被最先搜索。因为所有的聚集函数和操作符都被pg_catalog持有,这样的考虑是适当的。
但是如果显式将pg_catalog放到搜索路径中的话,将以指定的顺序进行搜索。如果事先准备与pg_catalog中的聚集函数和操作符同名的对象,pg_catalog中登录的“正规”对象会被替代。这样,SECURITY DEFINER函数中使用的对象可以被替换为恶意用户提供的对象,以他人的权限实施攻击。
相应的对策是,在SECURITY DEFINER函数的搜索路径中仅仅设定安全的schema。
上次说提出的“安全警告”正是这样。

沒有留言:

PostgreSQL & Google-Analytics Running...

::Planet PostgreSQL::

PostgreSQL Information Page

PostgreSQL日記(日本 石井達夫先生Blog)

PostgreSQL News

黑喵的家 - 資料庫相關

Google 網上論壇
PostgreSQL 8 DBA 專業指南中文版
書籍內容討論與更多下載區(造訪此群組)
目錄下載: PostgreSQL_8 _DBA_Index_zh_TW.pdf (更新:2007-05-18)

全球訪客分佈圖(Google)

全球訪客分佈圖(Google)