CVE-2020-5764：安卓MX Player播放器路径穿越和代码执行漏洞

 

0x00 绪论

MX Player是一个Android应用程序，可以在Google Play商店中找到它，下载量超过5亿。

虽然这是一个视频播放器应用，但我们不会使用畸形的视频文件对其进行攻击。我攻击的是它的视频共享功能。视频共享功能可以在手机间共享文件，其中有路径遍历漏洞（CVE-2020–5764）。我将展示如何找到该漏洞以及如何最终获得（对于某些设备）代码执行。幸运的是，由于我们已经向开发人员披露了此问题，所以问题已在v1.24.5中进行了修补，因此，如果你是MX Player用户，强烈建议你将其更新到此版本或更高版本。

 

0x01 MX Player发送者/接收者关系

MX Player通过将其中一部手机（“接收者”）设置为热点模式来在两部手机之间传输视频文件，而另一部手机（“发送者”）通过共享密码进行身份验证并通过此连接发送视频。然后，视频将保存到接收者的“/sdcard/MxShare”目录中。

在开始分析此漏洞之前，我先描述共享密码的实现存在的一个问题。当接收方将手机置于“热点”模式时，此热点的密码将以base64编码并作为可发现的蓝牙设备公开广播。

这意味着如果攻击者在接收方的蓝牙范围内，手机的热点密码就泄露了，随后我将要分析的问题同样可被附近的未认证攻击者利用。

 

0x02 利用媒体共享协议

该协议定义了传输过程中的各种命令。这些命令之一告诉应用程序传入文件要以什么文件名保存。

如果我们对应用程序的代码进行逆向，会找到该应用程序处理共享协议的部分。在其中，我们看到负责处理文件名的命令是“FILE_LIST”，并且当通过传输协议接收到此消息时，有参数告诉应用程序如何保存文件。预期的消息如下所示：

‘mxx00x01x00x02x00x00x00xb5{“hash”:”FA730A013D17D705CAF504B5CA560501",”id”:0,”name”:”cool_video”,”suffix”:”mp4",”size”:5976,”type”:0}

“mx”首部之后的“x01”是FILE_LIST命令，随后的JSON文本包含一个名为“name”的字段。在MX Player传输会话期间收到消息时，会把name和硬编码的路径“/sdcard/MXShare/”拼接起来。

你可能已经发现问题了，如果在此协议消息下传递的文件名为“../../traversedFile”，则可以进行路径穿越。

因此，发送如下消息：

s.sendall(b’mxx00x01x00x02x00x00x00xb5{“hash”:”FA730A013D17D705CAF504B5CA560501",”id”:0,”name”:”../cool_video”,”suffix”:”mp4",”size”:5976,”type”:0}

将导致视频保存在“/sdcard/MXShare”路径之外，并直接保存到sdcard根目录。

 

0x03 获得代码执行

试图通过它来获得代码执行时，我遇到了一点障碍。最初，我想穿越到“/data/data/com.mxtech.videoplayer.ad/” （我们可以写入的应用程序安装目录）并覆盖一些.dex文件（可执行的Android代码）以获取代码执行。不幸的是，保存文件的这个写操作无法覆盖现有文件……只能创建新文件。因此，要获得RCE，我们需要着眼于不存在的文件，但是如果我们创建这个文件…则可以获取代码执行…存在这样的文件吗？

为此，我在手机上运行了“strace”，以尝试查找该应用尝试读取的所有不存在的文件。我找到了一些，但最有趣的是“audience_network.odex”和“audience_network.vdex”。我需要在此应用程序启动时捕获文件I/O，因此我运行了以下命令：

am start -n com.mxtech.videoplayer.ad/com.mxtech.videoplayer.ad.ActivityWelcomeMX && ps -A | grep [m]x -m 1 | tr -s ‘ ‘ | cut -d ‘ ‘ -f2 | xargs strace -f -p 2>&1

执行完此操作后，我发现了该应用尝试打开但不存在的一些文件。最有趣的是“files/audience_network.dex”。下面，我grep了“audience_network”，并看到了几个包含该名称的文件。

这些是应用程序在运行时动态加载的FBaudiencenetwork dex文件的一部分，该文件似乎是某种Facebook广告Sdk，供应用程序开发人员使用（https://developers.facebook.com/docs/audience-network ）。在安卓中，“.dex”文件可以优化为“.odex”文件，这是使用AOT编译的dex代码的本机模块（提前编译 https://source.android.com/devices/tech/dalvik/configure ）。 如果ART运行时（libart.so）看到odex文件存在于“<app路径>”/files/oat/<架构>/*.odex”中，它将尝试加载并运行之。在我对Pixel 3a（出厂设置）和我个人拥有的Pixel 3 XL（均为Android 10）进行的测试中，这些优化文件似乎在安装应用后默认情况下不存在，这意味着它们容易受到这种攻击。

就像我之前提到的，odex是本机代码。在某些情况下，libart会使用dlopen调用（https://android.googlesource.com/platform/art/+/master/runtime/oat_file.cc#1104 ）将其作为共享对象加载。在这种情景下，只需针对手机架构编译一个共享对象，将其重命名为“audience_network.odex”（并新建一个空的“audience_network.vdex”文件）就可以在下次应用程序执行时获得代码执行。

 

0x04 利用

当用户处于“接收”模式时，攻击者可以连接到远程手机并与MX传输协议进行交互（如PoC中所示），以将可执行的.odex文件（以及.vdex）释放到/data/data/com.mxtech.videoplayer.ad/files/oat/<架构>/audience_network.odex。 MX传输协议可以支持在一个传输会话中发送多个文件，因此创建如下FILE_LIST消息就可以把这两个文件正确地放入路径中，以便在下次运行该应用程序时执行。

s.sendall(b’mxx00x01x00x02x00x00x00xb5{“hash”:”FA730A013D17D705CAF504B5CA560501",”id”:0,”name”:”../../../../../data/data/com.mxtech.videoplayer.ad/files/oat/arm64/audience_network.odex”,”suffix”:””,”size”:5976,”type”:0}x00x00x00xb2{“hash”:”BAF54A9DAD144105C1FF04B4E90FC901",”id”:1,”name”:”../../../../../data/data/com.mxtech.videoplayer.ad/files/oat/arm64/audience_network.vdex”,”suffix”:””,”size”:2,”type”:0}’)

 

0x05 修补

将问题披露给MX Player的过程中，我们很少收到厂商方面关于补丁进展的沟通。在后续偶尔进行的测试里，我们发现路径穿越问题已经于1.24.5版中修复。