Your application was found to be using dynamic code loading. While this is not a vulnerability per se, it is not a secure code practice and can lead to code injection or malicious side-loading of code. This mechanism allows a developer to specify which components of the application should not be loaded by default when the application is started. Typically, core components and additional dependencies are loaded natively at runtime, however, dynamically loaded components are only loaded as they are specifically requested. While this can have a positive impact on performance, or grant additional functionality (i.e. a non-invasive update feature), it can also open the application to serious security vulnerabilities if not implemented properly. Dynamic code loading, if performed using insecure mechanisms, can be vulnerable to arbitrary code execution. If vulnerable, an attacker may be able to use these issues to exploit the app, changing runtime activities.
Steps to Reproduce
Checks for the use of dynamic code loading within the APK.
Business Impact
This app allows other actors to change how it works. Those actors could inject code to modify how the app works, or gain access to confidential data on the device or network.
Remediation Resources
It is strongly discouraged to load code from outside of the application APK. Doing so significantly increases the likelihood of application compromise due to code injection or code tampering. It also adds complexity around version management, application testing and can make it impossible to verify the behavior of an application. Dynamically loaded code runs with the same security permissions as the application APK. If the modules are included directly within the APK, then they cannot be modified by other applications. This is true whether the code is a native library or a class being loaded using DexClassLoader. There can be instances of applications attempting to load code from insecure locations, such as downloaded from the network over unencrypted protocols or from world writable locations such as external storage. These locations could allow modification of the content in transit, or another application to modify the content on the device, respectively.
Finding Description
Your application was found to be using dynamic code loading. While this is not a vulnerability per se, it is not a secure code practice and can lead to code injection or malicious side-loading of code. This mechanism allows a developer to specify which components of the application should not be loaded by default when the application is started. Typically, core components and additional dependencies are loaded natively at runtime, however, dynamically loaded components are only loaded as they are specifically requested. While this can have a positive impact on performance, or grant additional functionality (i.e. a non-invasive update feature), it can also open the application to serious security vulnerabilities if not implemented properly. Dynamic code loading, if performed using insecure mechanisms, can be vulnerable to arbitrary code execution. If vulnerable, an attacker may be able to use these issues to exploit the app, changing runtime activities.
Steps to Reproduce
Checks for the use of dynamic code loading within the APK.
Business Impact
This app allows other actors to change how it works. Those actors could inject code to modify how the app works, or gain access to confidential data on the device or network.
Remediation Resources
It is strongly discouraged to load code from outside of the application APK. Doing so significantly increases the likelihood of application compromise due to code injection or code tampering. It also adds complexity around version management, application testing and can make it impossible to verify the behavior of an application. Dynamically loaded code runs with the same security permissions as the application APK. If the modules are included directly within the APK, then they cannot be modified by other applications. This is true whether the code is a native library or a class being loaded using DexClassLoader. There can be instances of applications attempting to load code from insecure locations, such as downloaded from the network over unencrypted protocols or from world writable locations such as external storage. These locations could allow modification of the content in transit, or another application to modify the content on the device, respectively.
Risk and Regulatory Information
Severity: medium CVSS: 4.3
Application
See more detail in the NowSecure Report