166 - OpenSSL Off-by-One, Java XML Bugs, and an In-the-Wild Samsung Chain
Off-by-one issue as the bounds check
if (written_out > max_out) will continue for one extra iteration after it has written
max_out number of integers.
The root of the issue is that XSLTC (turns XSLT into a Java Class to be executed for better performance) does not account for that fact that the
constant_pool_count in a Java class is only 16bits. An attacker can create an XSLT document containing too many constants, all of which will be written to the class file, but the count will be truncated to 16bits, leading to some of those constants being interpreted as part of the classfile containing things like field and method descriptions for the class.
The whole post gets deep into the background how XSLT is exposed through SAML assertions and verifying signatures (so part of the unauthenticated attack-surface) and into the details of actually crafting a valid classfile abusing this integer truncation.
An in-the-wild exploit chain was discovered that exploits three vulnerabilities in Samsung exynos devices running kernel 4.14.113. It consisted of one userland exploit in Samsung’s custom clipboard provider, a kernel infoleak through their
sec_log functionality, and finally a UAF in the Display Processing Unit (DPU) driver.
1. File read/write via Samsung clipboard provider
The Samsung clipboard provider is accessible via the system server, and is typically used for images. It maintains a database of IDs to URI paths to the backing file to open. The problem is, a calling process can insert URIs into the database by using the clipboard’s content provider. By inserting your malicious URI via
_data, you can obtain a raw file descriptor to any file the system server has access to, essentially giving you a privilege escalation as you can access files your regular process wouldn’t have access to.
2. Infoleak via sec_log
Samsung has a custom logging file,
/data/log/sec_log.log. Interestingly, this file is accessible to
system_app context even though the normal
kmsg is privileged off. Samsung copies
kmsg contents into
sec_log.log, and so by triggering a warning or any other action that dumps register contents to logs, kernel pointers could be obtained to defeat kASLR. They chained this with the first vulnerability to get a handle to
sec_log.log, and triggered a warning in the Mali GPU driver via providing an invalid
3. UAF in DPU kernel driver
Finally, the chain gets kernel read/write via a UAF in the
decon_set_win_config() function for the display and enhancement controller. This function would create a DMA fence and install a file descriptor labelled as
retire_fence. Once installed, its in the process FD table and thus can be accessed by anyone in the process. Later in this function,
decon_create_release_fences() is called, which installs another FD with the same backing file for
rel_fence. An attacker can close the installed file descriptor before
decon_create_release_fences() is called, and cause a UAF on the backing file object.
The way this was exploited was to point the file’s
private_data to the kernel
addr_limit. They then used
signalfd() to set the
addr_limit and get arbitrary read/write via a pipe. While devices would have User-Access-Overwrite (UAO) and Privileged Access Never (PAN), since the attacker has arbitrary write to the
addr_limit, they can set it as needed when passing data across and these mitigations are not effective in preventing arbitrary read/write.