I have previously written about Safe Coding for Android Apps, Android IPSec and Hardware Emissions, Security of Third Party Login Tokens, m-Payment and App Security and Mobile a Rising Security Threat. However, one thing I haven’t covered is vulnerabilities introduced due to hardware OEM sloppy coding.
While researching for a secure project I came across a US-CERT vulnerability. It’s to do with dmesg. Most Android developers won’t have come across this as it’s used for debugging the kernel as opposed to the application level (logcat). The problem is that some manufacturers have forgotten to take out their dmesg logging and PINs, passwords and other user-entered data can be exposed. It’s fairly easy for rogue app to listen in on the dmesg trace without having any special permissions. There are also apps on Google Play that can read dmesg (Here’s an open source one if you want to play).
For developers creating secure apps such as banking/payment apps, this can be especially tricky as it’s device-type specific. There’s no way to test for this as what isn’t exposed on one device type or firmware version might be on another. One way to code for this is to ensure your user authentication isn’t text based and hence not amenable to being written to a log file. However, you also have to be especially careful that what you are comparing the authentication against also doesn’t make any sense in textual form.