We all know that Google’s Android mobile operating system has garnered a notorious reputation of being pretty easy to hack and Google not doing enough towards data security. However, according to a security expert’s recent revelation, Jelly Bean (Android 4.1) is the most difficult Android OS to exploit till date. It’s thanks to a proper implementation of a security technique known as ASLR in Jelly Bean, even though it was first introduced in Ice Cream Sandwich (Android 4.0).
Jelly Bean’s improved security claim was made by security researcher Jon Oberheide on his security blog, Duo Security. According to his latest blog post, ASLR (or Address Space Layout Randomization) featured introduced in Android 4.0 ICS has been finally “implemented” in the latest Android 4.1 Jelly Bean release.
What’s the big deal about ASLR, we hear you ask? Here’s Oberheide’s explanation:
“ For the uninitiated, ASLR randomizes where various areas of memory (eg. stack, heap, libs, etc) are mapped in the address space of a process. Combined with complementary mitigation techniques such as non-executable memory protection (NX, XN, DEP, W^X, whatever you want to call it), ASLR makes the exploitation of traditional memory corruption vulnerabilities probabilistically difficult. ”
Although ASLR was introduced in ICS Android 4.0, “things weren’t in great shape,” claims Oberheide. But Jelly Bean’s proper implementation of ASLR is an important step towards securing future Android OS releases, and making it difficult for hackers to exploit vulnerabilities, opined Oberheide. ASLR when paired with another important security step known as data execution prevention or DEP and information leak prevention effectively fortifies Android 4.1 Jelly Bean’s security armour by several degree.
So yes, while we celebrate the increased security efficiency of Android’s Jelly Bean build, let’s not get carried away and think intrusions and hack attacks won’t happen. In Oberheide’s own words, Jelly Bean’s proper implementation of ASLR and DEP will make hackers’ job of exploiting memory corruption bugs more difficult, but not impossible.
Compared to Apple’s iOS, Google’s rival in the mobile OS war, Android still doesn’t support code signing -- a security step which authenticates the software author and the integrity of the executable code through a digital signature -- something that has been present in iOS since a long time.
What’s the big deal about ASLR, we hear you ask? Here’s Oberheide’s explanation:
“ For the uninitiated, ASLR randomizes where various areas of memory (eg. stack, heap, libs, etc) are mapped in the address space of a process. Combined with complementary mitigation techniques such as non-executable memory protection (NX, XN, DEP, W^X, whatever you want to call it), ASLR makes the exploitation of traditional memory corruption vulnerabilities probabilistically difficult. ”
Although ASLR was introduced in ICS Android 4.0, “things weren’t in great shape,” claims Oberheide. But Jelly Bean’s proper implementation of ASLR is an important step towards securing future Android OS releases, and making it difficult for hackers to exploit vulnerabilities, opined Oberheide. ASLR when paired with another important security step known as data execution prevention or DEP and information leak prevention effectively fortifies Android 4.1 Jelly Bean’s security armour by several degree.
So yes, while we celebrate the increased security efficiency of Android’s Jelly Bean build, let’s not get carried away and think intrusions and hack attacks won’t happen. In Oberheide’s own words, Jelly Bean’s proper implementation of ASLR and DEP will make hackers’ job of exploiting memory corruption bugs more difficult, but not impossible.
Compared to Apple’s iOS, Google’s rival in the mobile OS war, Android still doesn’t support code signing -- a security step which authenticates the software author and the integrity of the executable code through a digital signature -- something that has been present in iOS since a long time.
0 comments:
Post a Comment