KDE框架漏洞的原因及研究过程中的一系列思路

来源:岁月联盟 编辑:猪蛋儿 时间:2020-01-29

5.61.0版本以下的KDE框架(kf5/kdelibs)容易受到KConfig类中的命令注入漏洞的攻击,远程用户可以通过该漏洞查看经特殊设计的配置文件,直接利用此功能。唯一需要进行的交互是在文件浏览器或桌面上查看文件。当然,这需要用户下载一个文件,但是隐藏这个文件一点也不难。
以下是一个演示动图:

KDE框架漏洞的发现过程
我发现使用Origin的客户端是使用Qt框架编写的,而KDE也是使用Qt框架构建的,我可能会尝试研究一下,而这又促使我去查看KDE。
另一个可能在整个发现过程中起到一定作用的因素是,我一直在我的一台笔记本电脑上使用KDE,对它足够熟悉,所以我可以相当容易地找到攻击面。
因为我了解KDE,所以我决定首先查看它们的默认图像查看器(gwenview)。这背后的想法是,“如果我能在默认图像查看器中找到一个漏洞,那应该是一个相当可靠的漏洞”。当然,如果我们能够将有效载荷驻留在一个图像中,并在有人查看或在浏览器中打开它时触发它,那么事情就会变得非常简单。
当我意识到gwenview实际上编译了一个最近查看的文件列表,并使用KConfig配置语法来设置这些目录时,我才恍然大悟。

让我印象深刻的是shell变量,根据这些变量的解释方式,我们可能能够实现命令执行。很明显,在File1中它调用了$HOME/Pictures/kdelol.gif并解析了变量,否则gwenview怎么知道文件在哪里呢?
为了查看这些配置目录是否解释了shell变量/命令,我在Name2中添加了一些自己的输入。

在gwenview中查看之后,并没有什么不同?这很糟糕,所以我返回到配置文件以查看是否有任何更改。事实证明,gwenview在启动时会解释shell变量,因此为了解释这些最新文件,gwenview必须在配置文件更新后重新启动。
一旦发生这种情况,命令就会执行。

可以看到,Name2目录中的命令得到了解释,并解析了$(whoami)的输出。它之所以返回到Name1是因为我用File复制了目录。目前这对我们来说没有太大的区别,只要我们的命令在执行,就足以运行。
最初,我不知道$e应该是什么意思,所以我进行了必要的挖掘,找到了KDE系统配置文件的文档。
原来$e是用来告诉KDE允许shell扩展的,不过,这根本不是一个漏洞或一个突出的问题。但它确实看起来很危险,我相信滥用它还能有更多的办法。在发现KDE允许在配置文件中扩展shell之后。

于是,我在想也许可以通过文件名实现内容注入类型的有效载荷。我尝试了这个方法,不幸的是,KDE似乎可以正确地解析新目录并通过添加额外的$来转义它们。不管怎样,如果你要给某人发送一个包含了有效载荷的文件,那显然是可疑的。
最后,我还是回到了KDE,正在浏览一个需要查看隐藏文件(dotfiles)的目录。我转到“控制”>“显示隐藏的文件”,突然意识到它在当前工作目录中创建了一个.directory文件。
由于不确定这个.directory文件是什么,我查看了其中的内容。
[Dolphin]
Timestamp=2019,8,11,23,42,5
Version=4
[Settings]
HiddenFilesShown=true
我注意到,它似乎与KDE用于所有配置文件的语法一致。所以,我想知道是否可以用shell命令注入这些目录,因为在打开目录时,KConfig正在读取和处理.directory文件。
我尝试用shell命令注入版本目录,但是它一直被覆盖。也许KDE有一些现有的。也许KDE有一些现有的.directory文件可以告诉我一些信息,所以我开始寻找它们。
zero@pwn$ locate *.directory
/usr/share/desktop-directories/kf5-development-translation.directory
/usr/share/desktop-directories/kf5-development-webdevelopment.directory
/usr/share/desktop-directories/kf5-development.directory
/usr/share/desktop-directories/kf5-editors.directory
/usr/share/desktop-directories/kf5-edu-languages.directory
/usr/share/desktop-directories/kf5-edu-mathematics.directory
/usr/share/desktop-directories/kf5-edu-miscellaneous.directory
[...]
例如,让我们看一下kf5-development-translation.directory并查看其中的内容。
kf5-development-translation.directory:
[Desktop Entry]
Type=Directory
Name=Translation
Name[af]=Vertaling
[...]
Icon=applications-development-translation
我注意到在[Desktop Entry]标签中,某些具有键的目录被调用。例如,名称项上的af键:
Name[af]=Vertaling
由于KConfig确实在检查键的目录,让我们尝试使用$e选项添加一个键,就像前面提到的配置文档一样。
此时,真正让我感兴趣的事情是图标入口。在这里,它提供了设置当前目录或文件本身的图标的选项。如果文件只是简单地命名为.directory,它将为其所在的目录设置属性。如果该文件命名为有效载荷.directory,则仅有效载荷.directory文件具有图标,而不是父目录。为什么会这样工作?我们将在稍后讨论。
这意味着即使不打开文件也可以调用我们的图标目录,它可以被简单地导航到一个特定的目录。如果在这里使用$e键注入命令是可行的,那这也有点太简单了,不是吗?

[1] [2]  下一页