ClickHouse多个缝隙道理分析

颁布功夫 2022-03-21

一、缝隙概述


ClickHouse是俄罗斯yandex公司于2016年开源的云数据库治理系统 ，，，ClickHouse宽泛利用于云平台的大数据分析利用中 ，，，其用户蕴含uber、ebay、德意志银行、阿里巴巴、腾讯等。。。


近日 ，，，JFrog安全钻研团队披露了在ClickHouse DBMS中发现的7个缝隙 ，，，占有ClickHouse最低权限的攻击者能够通过这些缝隙使ClickHouse服务器崩�！！�、泄漏内存内容 ，，，甚至导致远程代码执行（RCE）。。。

缝隙影响了ClickHouse 21.10.2.15版本之前的所有版本。。。具体缝隙描述如下表所示：


图片1.png


二、措置建议


2021年10月18日颁布的ClickHouse 21.10.2.15版本修复了上述的7个缝隙 ，，，请尽快升级到ClickHouse 21.10.2.15及以来的版本。。。


下载链接：

https://github.com/ClickHouse/ClickHouse/releases/


缓解措施：

若是无法升级 ，，，请在服务器中增长防火墙战术 ，，，限度只允许特定IP的客户端接见WEB端口(8123)和TCP服务器端口(9000)。。。


三、缝隙分析


这些缝隙都存在ClickHouse Server处置压缩数据的要求处置过程中 ，，，ClickHouse Server支持对用户要求的附带数据进行压缩。。。用户能够在提议WEB要求时 ，，，将decompress标志设为1即可 ，，，举例如下：

cat query.bin | curl -sS —data-binary @-‘http://serverIP:8123/?user=xxx&password=xxx&decompress=1' 

查问的附带数据(query.bin)能够按下面的结构进行组织：


图片2.png


ClickHouse支持多种压缩体式 ，，，蕴含LZ4、Gorilla、Delta等多种压缩算法。。。ClickHouse Server凭据要求中附带数据的压缩算法标识 ，，，挪用分歧的解压算法来对数据进行解压。。。


3.1 LZ4算法介绍


LZ4压缩算法是LZ算法系列中的一种 ，，，也是目前综合效能最快的压缩算法之一。。。

一个LZ4压缩块由多个LZ4序列组成 ，，，LZ4序列由以下数据组成 ，，，如下图所示：


图片3.png

Token巨细为1字节 ，，，高4个bits为不成压缩数据(literal）的长度(literallength) ，，，而低4个bits为能够压缩数据(match)长度(match length)。。。若是literallength的值为0 ，，，则暗示后续数据里没有literal。。。由于literal length只有4比特来暗示 ，，，它的最大值为15。。。当literal数据的巨细大于等于15时 ，，，必要在Token字段后增长格外的字节来暗示literal的长度（Literal length+）。。。


若是match length的值为0 ，，，则暗示后续数据里没有match。。。由于matchlength只有4比特来暗示 ，，，它的最大值为15。。。当match数据的巨细大于等于15时 ，，，必要在offset字段后增长格外的字节来暗示match的长度（match length+）。。。

Literals指没有反复、初次出现的字节流 ，，，即不成压缩的部门。。。

Offset指的是此刻字符串离它的匹配项的长度 ，，，而匹配长度指的是此刻字符串与字典中一样字符串的匹配长度。。。offset占用2个字节 ，，，即最大值为65535。。。

Match指反复项 ，，，能够压缩的部门。。。


 3.2 CVE-2021-43304道理

src/Compression/LZ4_decompress_faster.cpp的decompressImpl函数在拷贝LZ4序列数据的literal时 ，，，没有判断复制的数据是否超过指标缓冲区的限度。。。当必要复制的数据超过指标缓存的巨细时 ，，，会导致堆溢出。。。


图片4.png


如上图代码所示 ，，，ip是指向压缩缓冲区的指针。。。op是指向分配的指标缓冲区的指针 ，，，该指标缓冲区的巨细为报头中给定的解压巨细。。。copy_end是指向复制区域结尾的指针。。。


copy_amount是模板的参数 ，，，可所以8、16或32。。。复制区域被分块复制 ，，，每个块的巨细都与复制量一样。。。

攻击者能够机关恶意的LZ4序列数据 ，，，其中litera的长度(length变量)大于dest_size ，，，将导致堆溢出。。。


3.3 CVE-2021-43304缝隙复现

我们能够机关这样的要求数据 ，，，其中压缩算法为LZ4 ，，，literal的长度为255*200 ，，，而dest_size为1。。。由于literal的巨细弘远于解压后缓冲区的巨细 ，，，当clickhouse_server进行复制操作时将导致堆溢出 ，，，触发法式崩溃。。。


图片5.png


3.4 CVE-2021-43305缝隙道理


缝隙存在src/Compression/LZ4_decompress_faster.cpp的decompressImpl函数中 ，，，该函数直接从LZ4压缩数据中读取16位无符号偏移量（offset攻击者能够节制） ，，，offset用于定位match数据的地位 ，，，当offset的值大于dest_size的值时 ，，，copyOverlap操作将导致堆溢出。。。


图片6.png


3.5 CVE-2021-42388及CVE-2021-42387缝隙道理


缝隙存在src/Compression/LZ4_decompress_faster.cpp的decompressImpl函数中 ，，，该函数直接从LZ4压缩数据中读取16位无符号偏移量（offset攻击者能够节制）,该偏移量用于推算wildCopy操作的源数据地址。。。当offset的值为大于copy_amount时(如offset = 0xffff） ，，，将导致法式将op地址之前的数据拷贝到op指向的地址中 ，，，从而导致越界读。。。


图片7.png


CVE-2021-42387是CVE-2021-42388的一个类似缝隙 ，，，这里就不再介绍。。。


3.6 CVE-2021-42389、CVE-2021-42390、CVE-2021-42391缝隙道理

ClickHouse支持的DoubleDelta编解码器、Delta编解码器、Gorilla编解码器中都存在被零除的缝隙。。。它们基于将压缩缓冲区的第一个字节设置为零。。。解压代码读取压缩缓冲区的第一个字节 ，，，并对其执行模运算以获得渣滓字节 ，，，当source[0]为0时 ，，，CPU对0进行取模时操作将产生除0异常。。。


图片8.png


四、实现语


大数据时期下 ，，，大量数据荟萃、衔接及网络天堑的延长都为数据库的的安全提出了更高的要求。。。数据库作为信息技术系统的主题和基础 ，，，承载着越来越多的关键业务系统 ，，，成为企业和机构最拥有战术性的主题数据资产 ，，，因而数据库方面的安全值得我们持续关注。。。


参考链接：

[1]https://jfrog.com/blog/7-rce-and-dos-vulnerabilities-found-in-clickhouse-dbms/

[2]https://github.com/ClickHouse/ClickHouse

[3]https://thehackernews.com/2022/03/multiple-flaws-uncovered-in-clickhouse.html