Kernel Buffer Overflow in Trusteer Rapport for MacOS
Trustwave recently reported a Kernel based vulnerability in a driver bundled along with IBM Trusteer Rapport for MacOS. The vulnerability is a signedness bug leading to a Kernel stack memory corruption issue in a call to memcpy. IBM Trusteer Rapport is security software advertised as an additional layer of security to anti-virus software. It is designed to protect confidential data, such as account credentials, from being stolen by malicious software (malware) and via phishing. Security issues in such software are of serious concern as the installation base of Trusteer Rapport is believed to be large given the backing of numerous US and EU financial institutions.
The Issue
The root cause of the issue is a signedness bug in validating the user-supplied number of elements provided by the user in the structure passed to the Kernel driver function via a call to an struct method exported from the Kernel driver with the IOService 'com_trusteer_rapportke_v2'. The code in question is shown below:
The validation at offset 0x23AE is later used in a signed-conditional mov instruction at offset 0x23B8, this comparison permits the user to provide a large unsigned value, for instance, -0xC, hence a negative signed value and thus by-pass this bounds check. The result is an integer overflow at offset 0x23C8 through the removal of the two most-significant bits resulting in a truncation permitting the user to specify a large user-definable length for the call to memcpy at offset 0x23D3.
The destination buffer happens to be situated in the data segment of the Kernel driver complicating exploitation, however, several structures are located within range facilitating several exploitation scenarios with which to obtain arbitrary code execution within the context of the Kernel and thus the successful compromise of the host.
Trustwave worked with IBM throughout the disclosure process. When IBM was unable to provide a patch during our 90-day disclosure policy, we extended to them an additional 30 days. Unfortunately, that was also not enough time to develop a patch, and we feel it's important to alert the public about this issue.
Although there is currently no patch, the risk of this vulnerability is slightly mitigated by requiring local access, so those affected are recommended to verify that only authorized users can log in to those systems. Security awareness training can also help prevent local malware or social engineering attacks. Finally, you may want to step up auditing of any affected systems for signs of infection.
Here is the full disclosure timeline:
08/15/2018 - Vulnerability disclosed to vendor
11/13/2018 - 90-day deadline passed
11/14/2018 - Provided vendor 30-day extension for fix
12/17/2018 - Vendor confirms no patch is available
12/20/2018 - Advisory published