1

I'm just starting out in Android and I've gotten my head around general programming within Android, but I've recently started trying to research security within Android.

What coding practices would you suggest I should avoid or programmatic situations to watch out for, in an effort to avoid overflow vulnerabilities?

Steve Dodier-Lazaro
  • 6,828
  • 29
  • 45

3 Answers3

4

Android is similar to other operating systems, if you code in Java then you shouldn't be worried about buffer overflows but if your code contains native code e.g. C++ or C, then you should avoid any possible buffer overflow vulnerabiliy. The instructions to avoid BOF in Linux can apply for android too, so you can use them.

http://www.cprogramming.com/tutorial/secure.html

Behzad
  • 71
  • 1
  • Welcome to our site Behzad! Could you please avoid linking to third-party resources and try to link to StackExchange sites instead? For instance http://security.stackexchange.com/questions/20497/stack-overflows-defeating-canaries-aslr-dep-nx or http://security.stackexchange.com/questions/55723/are-there-secure-languages/55731#55731 or http://security.stackexchange.com/questions/19600/why-dont-computers-check-whether-there-are-memory-contents-in-some-memory-space/19605#19605 . See [answer] for reasons why you should avoid third-party sites. – Steve Dodier-Lazaro May 23 '15 at 10:59
1

Java protects you from buffer overflow provided you don't call native methods (reference).

Neil Smithline
  • 14,702
  • 4
  • 38
  • 55
  • and actually capture exceptions – LvB May 23 '15 at 02:39
  • Not catching exceptions can lead to errant behavior but how can it lead to an exploit @LawrivanBuël? – Neil Smithline May 23 '15 at 03:26
  • I have been able to cause a code injection through not caught exception (not reliably but sometimes) it was with java 4 and it worked because the exception throw had as a side-effect to write my injection code into an object stored on disc that was read when the program was run again. – LvB May 24 '15 at 00:24
  • Do you think it was a JVM vulnerability @LvB? That seems possible to me. – Neil Smithline May 24 '15 at 03:09
  • Yes I do think its a JVM issue – LvB May 24 '15 at 03:23
1

Buffer overflows, as mentioned, are not possible in Java. There are Java (byte) arrays that more or less directly map to memory, but all array access is bounds checked (throwing an IndexOutOfBoundsException if anybody is reading beyond the limits. This is a runtime check of course. Note too that Java has references instead of pointers (NullPointerException is a bit of a misnomer). Pointer arithmetic is not supported. Of course IndexOutOfBoundsException is usually not caught, so it may still be used to perform a denial of service attack.

That doesn't mean that Java isn't vulnerable to other programming mistakes. You may end up with a memory related error if you leak resources, for instance.

For good coding practices, please take a look at e.g. the Google coding practices. These mainly specify syntax related practices. For general Java programming semantics you should at least read Effective Java.

Too few people use them, but it is a good idea to perform static code analysis on your generated source code and byte code. Two well known tools are CheckStyle for source code and FindBugs for byte code. It may pay off and use special applications that can perform automated testing of code as well. There is a myriad of companies that specialize in e.g. static testing. Many of these companies perform such analysis for free for open source applications.

You need to have JUnit tests, at least for any library class you write. Performing code coverage for your Unit tests is highly recommended. I'll leave out other practices such as application level testing and code review other than to mention that they exist. To be able to do all this you should use a well defined versioning system and build environment. If you have more than one developer then continuous integration usually pays off.

One of the most known security practices is to not trust the input to your application. You may want to create a separate threat analysis for your security design.

Maarten Bodewes
  • 4,602
  • 15
  • 29