Is Your Android App Insecure? Patching Security Functions With Dynamic Policy Based on a Java Reflection Technique

Abstract

With the popularization of smart devices, companies are adopting bring-your-own-device or mobile office policies that utilize personal smart devices for work. However, as work data are stored on individual smart devices, critical security threats are emerging, such as the leakage of confidential documents. Enterprises want to address this issue by adapting enterprise mobility management (EMM) solutions. Appwrapping is among the core technologies in EMM solutions, enabling security function insertion or misused code patching without the original application (app) source code. Studies on permission control, misused code patching, security function insertion based on static policies, etc., have been conducted, but there are limitations such as poor user convenience and overhead. In this paper, we propose an AppWrapper toolkit to support dynamic polices. Basically it can insert security function execution code into apps by using appwrapping technology without the original source code. This code uses Java reflection to invoke security functions dynamically based on preset policies. Accordingly, after the initial appwrapping, the policy can be changed easily. In addition, even when multiple security functions are required, Java reflection can invoke multiple security functions dynamically and simultaneously without conflicting with the existing code. The AppWrapper toolkit also provides a log function to check in real time where the security function is needed. Hence, the policy-setting administrator can check the log in real time and implement the security function where needed. Our experimental results show that this technique improves significantly the efficiency, effectiveness, and convenience of adding security function execution code.INDEX TERMS Mobile application, mobile computing, security management.

Runtime Software Patching: Taxonomy, Survey and Future Directions

“…Function-level patching is coarser compared to instruction-level patching as it targets patching whole functions [4,34].…”

“…For example, it replaces a buggy function with a patched one to eliminate vulnerabilities. A set of studies have proposed to perform function-level patching [4,9,24,25,[33][34][35][36][37]. Performing function-level patching requires taking crossfunction dependencies into consideration.…”

“…The steps of locating the patch target address are not much different compared to instruction-level patching. Several of the runtime patching approaches at function-level are designed for security patches [4,34,35,40]. For instance, Duan et al [35] have proposed OSSPatcher that automatically identifies vulnerable functions, generates binary patches and performs patch injection at runtime.…”

“…For instance, Duan et al [35] have proposed OSSPatcher that automatically identifies vulnerable functions, generates binary patches and performs patch injection at runtime. Similarity, Lee et al [34] have proposed an Appwrapper toolkit to inject additional security code on a per-method (i.e., function) basis into insecure apps enabling the use of dynamic policies to enhance overall application security. Function level patching are also performs to replace a whole vulnerable function by linking it with a new function or replacement code into kernel.…”

“…Most of these approaches are compiler assisted and implement function multiverse in the compiler to perform binary patching. [33] Dynamic variability in performance critical paths Patch deployment Semi-automated Cloud system, legacy code base AppWrapper [34] Applying dynamic security policies security functions Patch deployment Automated Mobile devices (Android) OSSPatcher [35] Patching Vulnerabilities Patch generation and deployment…”