解读2017-08-10发布的几个安全漏洞

本文涉及的产品
RDS PostgreSQL Serverless,0.5-4RCU 50GB 3个月
推荐场景:
对影评进行热评分析
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
RDS SQL Server Serverless,2-4RCU 50GB 3个月
推荐场景:
简介:

标签

PostgreSQL , 安全漏洞 , CVE-2017-7546 , CVE-2017-7547 , CVE-2017-7548


背景

PostgreSQL 社区于08-10发布了新版本,修复了三个安全漏洞。

https://www.postgresql.org/about/news/1772/

CVE-2017-7546:   
Empty password accepted in some authentication methods  
  
CVE-2017-7547:   
The "pg_user_mappings" catalog view discloses passwords to users lacking server privileges  
  
CVE-2017-7548:   
lo_put() function ignores ACLs  

下面一一进行解读。

CVE-2017-7546 允许空密码登陆漏洞

注意,libpq接口的客户端,都会自动拒绝空密码的用户登陆,这个行为可能误导用户认为空密码就是不允许登陆的。

而实际上并非如此,其他客户端驱动可能允许空密码登陆,这个漏洞修复了这个问题。在服务端拒绝空密码的用户登陆。

所以你如果不使用空密码,就不会有这个问题。

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=bf6b9e94445610a3d84cf9521032fab993f96fd6

Don't allow logging in with empty password.  
  
Some authentication methods allowed it, others did not. In the client-side,  
libpq does not even try to authenticate with an empty password, which makes  
using empty passwords hazardous: an administrator might think that an  
account with an empty password cannot be used to log in, because psql  
doesn't allow it, and not realize that a different client would in fact  
allow it. To clear that confusion and to be be consistent, disallow empty  
passwords in all authentication methods.  
  
All the authentication methods that used plaintext authentication over the  
wire, except for BSD authentication, already checked that the password  
received from the user was not empty. To avoid forgetting it in the future  
again, move the check to the recv_password_packet function. That only  
forbids using an empty password with plaintext authentication, however.  
MD5 and SCRAM need a different fix:  
  
* In stable branches, check that the MD5 hash stored for the user does not  
not correspond to an empty string. This adds some overhead to MD5  
authentication, because the server needs to compute an extra MD5 hash, but  
it is not noticeable in practice.  
  
* In HEAD, modify CREATE and ALTER ROLE to clear the password if an empty  
string, or a password hash that corresponds to an empty string, is  
specified. The user-visible behavior is the same as in the stable branches,  
the user cannot log in, but it seems better to stop the empty password from  
entering the system in the first place. Secondly, it is fairly expensive to  
check that a SCRAM hash doesn't correspond to an empty string, because  
computing a SCRAM hash is much more expensive than an MD5 hash by design,  
so better avoid doing that on every authentication.  
  
We could clear the password on CREATE/ALTER ROLE also in stable branches,  
but we would still need to check at authentication time, because even if we  
prevent empty passwords from being stored in pg_authid, there might be  
existing ones there already.  
  
Reported by Jeroen van der Ham, Ben de Graaff and Jelte Fennema.  
  
Security: CVE-2017-7546  

CVE-2017-7547 允许未授予USAGE权限的用户读取foreign server配置

这个漏洞和foreign server有关,通常某个用户u1要使用FOREIGN SERVER需要分为几个步骤。

1、创建foreign server S1,里面包含SERVER的连接信息。

2、赋予foreign server S1的usage权限给某个用户u1。(本漏洞所在。)

3、基于这个foreign server S1创建u1的user mapping,里面包含登陆这个foreign server的信息。

4、现在u1可以基于这个foreign server S1创建外部表。

现在的漏洞是,没有操作第2步,普通用户u1可以查询pg_user_mapping表,得到登陆这个foreign server的信息(例如连接这个外部server的用户和密码)。

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=e568e1eee4650227170cf8c64eedb74bafd7d1f0

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=3eefc51053f250837c3115c12f8119d16881a2d7

Again match pg_user_mappings to information_schema.user_mapping_options.  
  
Commit 3eefc51053f250837c3115c12f8119d16881a2d7 claimed to make  
pg_user_mappings enforce the qualifications user_mapping_options had  
been enforcing, but its removal of a longstanding restriction left them  
distinct when the current user is the subject of a mapping yet has no  
server privileges.  user_mapping_options emits no rows for such a  
mapping, but pg_user_mappings includes full umoptions.  Change  
pg_user_mappings to show null for umoptions.  Back-patch to 9.2, like  
the above commit.  
  
Reviewed by Tom Lane.  Reported by Jeff Janes.  
  
Security: CVE-2017-7547  

https://git.postgresql.org/gitweb/?p=postgresql.git;a=blobdiff;f=src/test/regress/expected/foreign_data.out;h=927d0189a0c26c5875cbe5af44d71d3819bd34eb;hp=7f2f529393d6682a69702cb32d3975074b97f87d;hb=e568e1eee4650227170cf8c64eedb74bafd7d1f0;hpb=bf6b9e94445610a3d84cf9521032fab993f96fd6

已修复后,例子

-GRANT USAGE ON FOREIGN SERVER s10 TO regress_unprivileged_role;  
--- owner of server can see option fields  
+CREATE USER MAPPING FOR regress_unprivileged_role SERVER s10 OPTIONS (user 'secret');  
  
+-- unprivileged user cannot see any option field  
 SET ROLE regress_unprivileged_role;  
 \deu+  
               List of user mappings  
  Server |         User name         | FDW options   
 --------+---------------------------+-------------  
  s10    | public                    |   
+ s10    | regress_unprivileged_role | -- 未修复时,这里会显示user 'secret'  
  s4     | regress_foreign_data_user |   
  s5     | regress_test_role         |   
  s6     | regress_test_role         |   

老版本要修复这个问题,请参考 https://www.postgresql.org/about/news/1772/ ,需要修改系统表的信息。

所以,如果你继续使用老版本,你要回收某个用户的foreign server权限,请同时删除user mapping。就不会有问题。

CVE-2017-7548 大对象操作函数lo_put()未检测写权限

漏洞描述:

在没有某个大对象的UPDATE权限时,用户依旧可以使用lo_put()函数操作这个大对象。

修复后,需要赋予这个大对象UPDATE权限,才可以调用lo_put()操作这个大对象。

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=8d9881911f0d30e0783a6bb1363b94a2c817433d

Require update permission for the large object written by lo_put().  
  
lo_put() surely should require UPDATE permission, the same as lowrite(),  
but it failed to check for that, as reported by Chapman Flack.  Oversight  
in commit c50b7c09d; backpatch to 9.4 where that was introduced.  
  
Tom Lane and Michael Paquier  
  
Security: CVE-2017-7548  

修复后的例子如下

src/test/regress/expected/privileges.out

SET SESSION AUTHORIZATION regress_user1;  
1186 SELECT lo_create(1001);  
1187  lo_create   
1188 -----------  
1189       1001  
1190 (1 row)  
1191   
1192 SELECT lo_create(1002);  
1193  lo_create   
1194 -----------  
1195       1002  
1196 (1 row)  
1197   
  
  
1216 GRANT ALL ON LARGE OBJECT 1001 TO PUBLIC;  
1217 GRANT SELECT ON LARGE OBJECT 1003 TO regress_user2;  
1218 GRANT SELECT,UPDATE ON LARGE OBJECT 1004 TO regress_user2;  
1219 GRANT ALL ON LARGE OBJECT 1005 TO regress_user2;  
1220 GRANT SELECT ON LARGE OBJECT 1005 TO regress_user2 WITH GRANT OPTION;  
1221 GRANT SELECT, INSERT ON LARGE OBJECT 1001 TO PUBLIC;    -- to be failed  
1222 ERROR:  invalid privilege type INSERT for large object  
1223 GRANT SELECT, UPDATE ON LARGE OBJECT 1001 TO nosuchuser;    -- to be failed  
1224 ERROR:  role "nosuchuser" does not exist  
1225 GRANT SELECT, UPDATE ON LARGE OBJECT  999 TO PUBLIC;    -- to be failed  
1226 ERROR:  large object 999 does not exist  
1227 \c -  
  
1228 SET SESSION AUTHORIZATION regress_user2;  
  
1299 -- confirm ACL setting  
1300 SELECT oid, pg_get_userbyid(lomowner) ownername, lomacl FROM pg_largeobject_metadata WHERE oid >= 1000 AND oid < 3000 ORDER BY oid;  
1301  oid  |   ownername   |                                             lomacl                                               
1302 ------+---------------+------------------------------------------------------------------------------------------------  
1303  1001 | regress_user1 | {regress_user1=rw/regress_user1,=rw/regress_user1}  
1304  1002 | regress_user1 |   
1305  1003 | regress_user1 | {regress_user1=rw/regress_user1,regress_user2=r/regress_user1}  
1306  1004 | regress_user1 | {regress_user1=rw/regress_user1,regress_user2=rw/regress_user1}  
1307  1005 | regress_user1 | {regress_user1=rw/regress_user1,regress_user2=r*w/regress_user1,regress_user3=r/regress_user2}  
1308  2001 | regress_user2 | {regress_user2=rw/regress_user2,regress_user3=rw/regress_user2}  
1309 (6 rows)  
  
  
+SELECT loread(lo_open(1001, x'20000'::int), 32);   -- allowed, for now  
+ loread   
+--------  
+ \x  
+(1 row)  
+  
+SELECT lowrite(lo_open(1001, x'40000'::int), 'abcd');  -- fail, wrong mode  
+ERROR:  large object descriptor 0 was not opened for writing  
  
+SELECT lo_put(1002, 1, 'abcd');                -- to be denied  
+ERROR:  permission denied for large object 1002  
相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
目录
相关文章
|
存储 NoSQL 关系型数据库
PostgreSQL列存扩展hydra简单测试
Hydra是一款PostgreSQL的扩展,为PostgreSQL增加了列存引擎,使得PostgreSQL的olap性能大幅提升,本文介绍Hydra基本的使用方法。
|
关系型数据库 数据库 索引
AnalyticDB for PostgreSQL 黑科技解析 - 列存储 Meta Scan 性能加速
本文介绍阿里云 AnalyticDB for PostgreSQL(原HybridDB for PostgreSQL) 产品,即 MPP 数据仓库服务,其列存储 meta scan机制,及其对 分析场景的性能提升。
2785 0
|
9月前
|
安全 算法 API
OpenSSL支持哪些加密算法?
【10月更文挑战第4天】OpenSSL支持哪些加密算法?
566 5
|
8月前
|
监控 JavaScript 算法
如何使用内存监控工具来定位和解决Node.js应用中的性能问题?
总之,利用内存监控工具结合代码分析和业务理解,能够逐步定位和解决 Node.js 应用中的性能问题,提高应用的运行效率和稳定性。需要耐心和细致地进行排查和优化,不断提升应用的性能表现。
307 77
|
7月前
|
机器学习/深度学习 人工智能 编译器
【AI系统】AI 编译器历史阶段
本文概述了AI编译器的发展历程,从朴素AI编译器、专用AI编译器到未来的通用AI编译器,详细介绍了各阶段的技术特点与优化目标。AI编译器旨在优化AI和机器学习应用,通过多层IR设计、面向神经网络的深度优化及对DSA芯片的支持,实现高性能计算。随着技术的进步,通用AI编译器将实现计算图与算子的统一表达、自动化优化及模块化设计,推动AI技术的广泛应用和发展。
216 2
|
11月前
|
SQL 安全 关系型数据库
PostgreSQL SQL注入漏洞(CVE-2018-10915)--处理
【8月更文挑战第8天】漏洞描述:PostgreSQL是一款自由的对象关系型数据库管理系统,支持多种SQL标准及特性。存在SQL注入漏洞,源于应用未有效验证外部输入的SQL语句,允许攻击者执行非法命令。受影响版本包括10.5及更早版本等。解决方法为升级PostgreSQL
562 2
|
12月前
|
Java 应用服务中间件 Go
证书格式有哪些,区别以及如何生成证书
证书格式有哪些,区别以及如何生成证书
565 4
|
存储 OLAP 数据处理
GaussDB技术解读——GaussDB架构介绍(三)
GaussDB技术解读——GaussDB架构介绍(三)
428 1
|
Java 项目管理 Maven
Java一分钟之-Maven profiles与dependencyManagement
【6月更文挑战第5天】本文探讨了Maven的profiles和dependencyManagement特性在Java项目管理中的应用,包括基本概念和常见问题。Profiles用于根据不同环境激活配置,易错点在于忘记激活,应通过命令行或设置默认profile来避免。dependencyManagement集中管理依赖版本,过度依赖会导致子模块灵活性降低,应合理使用。结合两者,可在不同环境中控制依赖版本,提高项目配置效率。
351 8
|
开发框架 运维 供应链
如何进行资产梳理(上)
本文介绍了资产梳理的重要性,特别是对于蓝队成员在护网行动中的准备工作。资产梳理包括安全防护设备、对外开放服务项目和项目外包业务流程的详细信息整理,如设备型号、版本、责任人等。此外,还提到了两种资产梳理方式:一是关注业务资源、设备资产和第三方服务信息;二是识别和管理账号权限、互联网风险、后台目录风险、旁站风险、C段风险和端口风险。文章强调了暴露面收敛的重要性,如关闭非必要服务和端口,以降低安全风险。最后,作者总结了资产梳理的步骤,认为这与Web信息收集类似,是蓝队防御的关键环节。
1482 6