Allele Security Alert
Loading of arbitrary Kernel Extensions
LiquidVPN for macOS
LiquidVPN 1.37, 1.36 and earlier
Proof of concept
LiquidVPN installs the helper tool “com.smr.liquidvpn.OVPNHelper” for performing privileged (root) actions. In order to allow other LiquidVPN components to send messages to the helper tool, it implements an XPC service. Static code analysis showed, that the XPC service does not filter incoming messages. This means, regular users (local attackers) can craft arbitrary XPC messages and send them to the service.
If the service detects the “openvpn” parameter in a message, it also checks if the parameters “tun_path” or “tap_path” exist. If one of them (or both) are found, the values are used as source paths for a copy process using the system() function. However, the paths are not sanitized before being passed to system().
This vulnerability can be used to directly install an arbitrary kernel extension or code execution.
By crafting an XPC message containing attacker controlled kernel extension paths, the helper tool installs the kernel extensions using a call to the system function kextload(). Note: Since MacOS 10.13, a Kext needs to be signed. In addition to that, Apple introduced user-approval for installing third party kernel extensions. However, as an attacker has local access to the system and user-approval does not require the user to enter a root or admin password, this is not a problem.
The following proof of concept can be used to execute arbitrary system commands:
--- ... xpc_dictionary_set_string(message, "cmd", "openvpn"); xpc_dictionary_set_string(message, "path_tun", "[PATH TO KEXT]"); ... ---
Multiple Privilege Escalation Vulnerabilities in LiquidVPN for MacOS (CVE-2018-18856, CVE-2018-18857, CVE-2018-18858, CVE-2018-18859)
If there is any error in this alert or you wish a comprehensive analysis, let us know.
Last modified: February 1, 2019