MASTG-TEST-0043: Memory Corruption Bugs

This test will be updated soon

The test can be used in its current form, but it will receive a complete overhaul as part of the new OWASP MASTG v2 guidelines.

Help us out by submitting a PR for: MASTG v1->v2 MASTG-TEST-0043: Memory Corruption Bugs (android)

Send Feedback

Overview

Static Analysis

There are various items to look for:

• Are there native code parts? If so: check for the given issues in the general memory corruption section. Native code can easily be spotted given JNI-wrappers, .CPP/.H/.C files, NDK or other native frameworks.
• Is there Java code or Kotlin code? Look for Serialization/deserialization issues, such as described in A brief history of Android deserialization vulnerabilities.

Note that there can be Memory leaks in Java/Kotlin code as well. Look for various items, such as: BroadcastReceivers which are not unregistered, static references to Activity or View classes, Singleton classes that have references to Context, Inner Class references, Anonymous Class references, AsyncTask references, Handler references, Threading done wrong, TimerTask references. For more details, please check:

• 9 ways to avoid memory leaks in Android
• Memory Leak Patterns in Android.

Dynamic Analysis

There are various steps to take:

• In case of native code: use Valgrind or Mempatrol to analyze the memory usage and memory calls made by the code.
• In case of Java/Kotlin code, try to recompile the app and use it with Squares leak canary.
• Check with the Memory Profiler from Android Studio for leakage.
• Check with the Android Java Deserialization Vulnerability Tester, for serialization vulnerabilities.