On Mon, Nov 5, 2012 at 8:42 AM, cdcdrm <cdc...
> I have some items in mind:
> 1. check sensitive information leak
> 2. verify input before using them(to avoid fake intents).
> any other suggestions? thanks.
One of the few Secure Coding Guides I have seen in the mobile space is
published by VIA Forensics.
Its not a complete list, but it covers many of the major topics. Its
hard to come up with a complete list.
> Are there buffer overflow risks on Android?
It depends. Are you using JNI?
Android Java will use overflow/underflow during normal operations and
wait (hope?) for the IndexOutOfBounds exception. Confer,
> For App testing, should 'exploit' be checked? common Apps should have no
> 'exploit' issues, correct?
It depends. What is the policy on vulnerable handsets? Is an emplyee
allowed to access corporate resources when the handset contains a
Patching is a serious problem in nearly all mobile, and most (not all)
handsets will have vulnerabilities available which lead to root. You
can test for those with X-Ray (http://www.xray.io).
The problem here is twofold: (1) AOSP consumes Linux kernel sources
without much review on good faith. The Linux kernel guys make more
Comp Sci 101 mistakes than a college freshman. For some reason, when
you are l33t, you don't have to validate parameters or check return
values. Dan Rosenberg (et al) have made a security career out of
finding their bugs. (2), there is no reason to fix those bugs when
found. We are waiting for OEMs and handset manufacturers to "do the
right thing", but there is no incentive to do so. Because "Do Nothing"
is cost effective, the bugs fester and rot.
Its not just Android that allows handsets to fester with bugs. Apple
does it too. Nearly 200 vulnerabilities were placed on the shelf while
Apple got its iPhone 5/iOS 6 press release together. Confer
To fix this problem, it looks like we need an act of congress
(literally) - software liability laws with teeth.