
Android phone users widely cover up mobile phone market. We understand that no hack proof devices in the world. Even though iphone iOS before 10.2.1 is vulnerable to DoS Exec Code Overflow (CVE-2017-2370). As a Android user we are not surprise Android operation system bug. There are 2 critical bug occurs on mediaserver and surfaceflinger. A bug was found on 2014 identify that a potential memory leak in SurfaceFlinger on Android 4.4.4. Memory leak due to not complete designed or programmed applications limitation that fail to free up memory segments when they are no longer needed. Since this is design fault (bug), as time goes by bug become a vulnerability found by security expert last month. The CVE alert that attacker is able to use a specially crafted file to cause memory corruption during media file and data processing on Android 7.0. Apart from that, media server found new vulnerability. Such vulnerability also affects the libhevc library. As far as we know, to improve device security on Android 7.0. Andriod breaks up the monolithic mediaserver process into multiple processes with permissions and capabilities restricted to only those required by each process. However a design weakness causes the vulnerability located in the function that created the native handle. When passing in well-structured numFds and numInts (such as numFds = 0xffffffff, numInts = 2) to native_handle_create, you can cause the expression “sizeof (native_handle_t) + sizeof (int) * (numFds + numInts)” Integer overflow.
Below code is a proof of concept shown that each GraphicBuffer object contains a pointer to a native handle.
native_handle_t* native_handle_create(int numFds, int numInts)
{
native_handle_t* h = malloc(
sizeof(native_handle_t) + sizeof(int)*(numFds+numInts));//———->Integer overflow position
h->version = sizeof(native_handle_t);
h->numFds = numFds;
h->numInts = numInts;
return h;
}
For details about vulnerabilities on Android. Please refer to below url for reference.
https://source.android.com/security/bulletin/2017-02-01.html
We heard that the overall comment on Android phone is not secure any more! As a matter of fact, design fault and design limitation are the element of the result. Since no prefect product was made in the world. Even though you put more time in development and staging phase can’t avoid a design fault occurs in your product. Yes, agree, shorten the development life cycle will hits the design fault encounter in frequent way. However modern mobile phone world integrate with Multi-application and functions. Sometime a 3rd party application will integrate into your mobile phone. Thus Andriod 7 contains defense mechanism to protect memory space and Kernel environment. But what is the fact causes the operating system still vulnerable? Ok, Let go together on this journey to elaborate more techincal details in this regard.
The evolution of Android 7.0
Android 7.0 includes a variety of system and API behavior changes.
Battery and Memory
Background Optimizations
Permissions Changes
Sharing Files Between Apps
Accessibility Improvements
NDK Apps Linking to Platform Libraries
Check if your app uses private libraries
TLS/SSL Default Configuration Changes
On above feature enhancement, it looks that the improvement on new version of Android looks fine. As said, no prefect product design in the world. On the other way of thinking, what if we become a hacker. On above items, which part will become vulnerable or weakness let attacker compromise the phone?
Observational standpoint:
Point 1: (Sharing Files Between Apps)
Regarding to technical details written on technical documentation. For apps targeting Android 7.0, the Android framework enforces the StrictMode API policy that prohibits exposing file:// URIs outside your app. If an intent containing a file URI leaves your app, the app fails with a FileUriExposedException exception. To share files between applications, you should send a content:// URI and grant a temporary access permission on the URI. The easiest way to grant this permission is by using the FileProvider class.
Side effect of Point 1 – Hacker can make use of File Provider class feature try to dig out the mobile phone data. The easy way is embedded a malicious program script in 3rd party application. Fool the user to click the button (accept sharing files between apps) during software installation. Since many mobile phone users are smart today, but still have many people fall down to this trap.
Point 2: (Memory)
Both the Android Runtime (ART) and Dalvik virtual machine perform routine garbage collection, this does not mean you can ignore when and where your app allocates and releases memory. Software designer need to avoid introducing memory leaks, usually caused by holding onto object references in static memory variables, and release any Reference objects at the appropriate time as defined by lifecycle callbacks.
Side effect of Point 2 – The easiest way to leak an Activity is by defining a static variable inside the class definition of the Activity and then setting it to the running instance of that Activity. If this reference is not cleared before the Activity’s lifecycle completes, the Activity will be leaked. So all depends on mobile apps developer design. It is hard to avoid memory leak. As you know, what is the defect of memory leak? Hacker relies on this error can implant malware.
Point 3: (Background Optimizations)
ART (Android run-time)
Starting with Android 5.0, Android Runtime (ART) replaces Dalvik as the default virtual machine in the system.


Reference: The Dalvik Virtual Machine (Dalvik VM)
The Android platform leverages the Dalvik Virtual machine (Dalvik VM) for memory, security, device, and process management. Application designer can think of the Dalvik VM as a box that provides the necessary environment for you to execute an Android application sans, and therefore not to worry about the target device (mobile phone system).
Side effect of Point 3 – ART became the default runtime. While Dalvik relies on interpretation and just-in-time compilation, ART precompiles app Dalvik bytecode into native code. The command responsible for compiling an application into OAT is dex2oat, which can be found in /system/bindex2oat. All mobile apps will be compiled every time the device’s system is upgraded or the first time it is booted up after it is purchased. So attacker might have way to use dex2oat to generate OAT files from modified versions of installed apps or system frameworks and replace the original OAT files with them. This is the famous attack hiding behind Android Runtime. Yes, compile method sounds like jail break of the mobile phone device. Even though iPhone can’t avoid. And therefore I still believe Android security not such poor because no products on the market can say it is hackproof.
Remark: Did you heard that hacker prepare scam email lure the user to upgrade their Android phone. It is the similar case which bring with my concerns.
Reference: Critical vulnerabilities on iPhone and Android found on Feb 2017.
| Apple » Iphone IOS | |||||
| score | Publish Date | Update Date | |||
| CVE-2017-2370 | 9.3 | DoS Exec Code Overflow | 2017-02-20 | 2017-02-22 | |
| CVE-2017-2360 | 9.3 | DoS Exec Code | 2017-02-20 | 2017-02-22 |
| Andriod OS | |||||
| CVE-2017-0405 | 9.3 | Remote code execution vulnerability in Surfaceflinger | 2017 | 2017 Feb | |
| CVE-2017-0406, CVE-2017-0407 | 9.3 | Remote code execution vulnerability in Mediaserver | 2017 | 2017 Feb | |
Summary:
If people tell you that a new mobile device is excellent, less vulnerabilities found. It is a perfect design. Even though he is the best at this moment. But believed that it is hard to maintain the glory in the long run. Why, because of today business on demand business strategy. If you heard that Android operating not secure anymore, but it is properly not.
















