A blog about performance testing and programming

You may have heard in the news about a recently announced vulnerability in the Stagefright media library in Android. The good people at Zimperium proudly announce on their blog that they’ll be unveiling “the worst Android vulnerability in the mobile OS history!” at a conference. This has garnered a lot of press, in large part because the media loves big headlines like “95% of android devices vulnerable”. This is of course great for Zimperium, because their recommended fix is “buy our shit” (FYI, don’t buy their shit – mobile security and anti-virus is almost entirely snake oil).

So how serious is this? Well, remote code execution is always bad news. Google were quick to point out that Android’s sandboxing model would limit the damage the exploit could do – so if the exploit were triggered in the Facebook app, then it would only have access to the same features Facebook does. But this may not be much comfort, since the example Zimperium give uses the Hangouts app, and Google have a tendency to give their own apps privileged access to the system.

But is it the “WORST EXPLOIT EVAR!”? From an Android perspective, maybe. The Samsung SwiftKey vulnerability is a contender, but isn’t exploitable without user interaction (connecting to a compromised WiFi hotspot). The Stagefright vulnerability appears to be exploitable without user intervention, with only hints that you’ve been compromised, and could affect a wider range of devices. However, it’s probably not the worst ever vulnerability, since Windows and Linux have suffered comparable breaches before. Also, Android’s device fragmentation may help it here, since attacks may need to be tweaked to work on different devices, so in practice penetration may be lower than feared.

It also goes without saying that not all the details of this exploit have been published, and it may transpire that Zimperium have oversold the power of their attack.

The key question, as always, will be how fast handset manufacturers can push out security updates. Google have made patches available to handset manufacturers (although interestingly they don’t appear to be in AOSP yet, although they are in CyanogenMod), so with luck, updates should be available shortly (for devices whose manufacturers still provide updates, at least).

Not long after I started in performance testing, I was debugging a script. It didn’t seem to like one of the requests the script
made, so I did what I would have done at home. I ran through the procedure manually, and watched in Wireshark.

I told a colleague about this, and he said “Don’t ever do that again, and don’t tell anyone that you did it”. The client I was working for at the time were very nervous about security, and would have been furious that I’d used Wireshark on their network.

Memory leaks have been a fact of life in programming for as long as anyone can remember. C is the mac daddy of memory leaks – any non-trivial program has a memory leak – but even in garbage collected languages you’re not safe, as there are some types of resource that you have to remember to close (OS-native objects, like files and processes).

Since Play is an external framework, you might guess that you want to have quite tight integration, using SessionFactory.externalTransactionAdapter. However, the right answer turns out to be looser integration, using SessionFactory.concreteFactory, which means you have to use explicit inTransaction blocks.

So what’s the problem? Well, Play’s database support is deliberately minimal. It provides a connection pool, and handles evolutions for you, but otherwise it’s up to you how you use it. It won’t commit or rollback your transactions unless you ask it to, which means you’re probably best off using inTransaction blocks anyway.

Problem solved, right? Well, almost. There’s still a slight impedance mismatch between Play and Squeryl. Play uses an asynchronous event-driven model, whereas Squeryl is designed for a connection-per-thread model.