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?

closed as too broad by Mark, Steve Dodier-Lazaro, Steve, schroeder, TildalWave May 24 '15 at 17:07

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

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

1

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

  • and actually capture exceptions – LvB May 23 '15 at 2: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 3: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 0:24
  • Do you think it was a JVM vulnerability @LvB? That seems possible to me. – Neil Smithline May 24 '15 at 3:09
  • Yes I do think its a JVM issue – LvB May 24 '15 at 3: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.

  • And that's just to get started :) – Maarten Bodewes May 24 '15 at 10:28