Remote Code Execution Vulnerability on LG SmartphonesMay 8, 2018
Research By: Slava Makkaveev
A few months ago, Check Point Research discovered two vulnerabilities that reside in the default keyboard on all mainstream LG smartphone models (termed by LG as ‘LGEIME’). These vulnerabilities are unique to LG devices, which account for over 20% of the Android OEM market in the US, according to a 2017 survey. The vulnerabilities were tested and proven exploitable on some of LG’s flagship devices, including LG G4, LG G5, and LG G6.
Check Point responsibly disclosed both vulnerabilities to LG, who released a patch yesterday in their May security update (LG has combined these two vulnerabilities into one: LVE-SMP-170025).
Both vulnerabilities could have been used to remotely execute code with elevated privileges on LG mobile devices by manipulating the keyboard updating process, act as a keylogger and thereby compromise the users’ privacy and authentication details. The first vulnerability was the use of an insecure connection used for a sensitive process, and the second was a validation flaw in LG’s file system.
The First Vulnerability
LG’s keyboard supports handwriting modes in various languages, with English being preinstalled on the device as default, and other languages defined by the user. When a new language or an update for an existing one is installed, the device reaches out to a hardcoded server from which it retrieves the requested language file. This download, however, is done over an insecure HTTP connection, exposing it to Man-in-The-Middle attacks and other manipulations. Such an attack could cause the device to download a malicious file instead of the language file it intended to download.
How Is it Done?
Each handwriting language pack is presented in the LG keyboard application by a separate folder: /data/data/com.lge.ime/VODB/<database version>/<language ID>.
Figure 1: English language handwriting directory.
A language pack consists of resource files related to a machine learning model and a files.txt metadata file. files.txt contains a list of all other files related to the current language pack. Each file is presented here by its file name, md5 hash of the file content and the file size.
Figure 2: files.txt metadata file content.
The handwriting language updating process, as well as the new language downloading process, consists of two logical phases:
- Downloading of the files.txt metadata file.
- Parsing of the metadata file and downloading of all resource files listed in it.
Each download, however, is performed through an insecure HTTP connection. The following URL will be used to download the English language pack http://lgresources.visionobjects.com/18.104.22.168/en_US.
Figure 3: Update traffic for English language handwriting.
Because of the unsecured connection, a language files.txt metadata file can be altered by a Man-in-the-middle proxy. Additional file entries can be injected in files.txt and LG keyboard process will download rogue file from controllable by MITM proxy URL.
The Second Vulnerability – Location Manipulation
The location on the disk of a downloaded file is also controllable by a MITM proxy. As previously mentioned, a resource file location depends on the file name, as indicated in the files.txt metadata file. Through a path traversal mechanism, this name can be treated as the location and modified to any other path within the LG keyboard package sandbox.
Figure 4: files.txt patched with path traversal.
LG’s keyboard application assumes that a native lib file can be part of a language pack and grants executable permissions for all downloaded files with extension .so. So, if the metadata file is extended with a .so file, entry to the rogue lib file will be marked on the disk as executable.
Triggering a Rogue Lib
Once the rogue .so file is placed on the file system, we need to force LG keyboard application to load it. One possible way to run the rogue lib is to indicate this lib as “input method extension library” in the keyboard configuration file: /data/data/com.lge.ime/files/Engine.properties.
Figure 5: Engine.properties patched with custom path to rogue library.
By altering the files.txt metadata file, the Engine.properties file can also be overwritten by a fake one in the same way as the lib injection was.
Figure 6: Fully patched files.txt ready for attack.
LG’s keyboard loads the libs indicated in Engine.properties configuration file on the application’s startup and the rogue lib we’ve injected inside the aforementioned file would be loaded as soon as the keyboard process restarts.
Once we manage to inject the rouge lib inside Engine.properties, all we need to do is wait for the application to restart and load the library. That is our ultimate goal and the moment it is reached then the attack ends.