Android Stagefright Vulnerability – Beyond The Hype

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).

But what is the vulnerability, and is it as serious as claimed?

Based on the patches submitted by Joshua Drake, we can take an educated guess at what the vulnerability is, and how it could be exploited. The patches fix a series of integer overflow and underflow bugs, in bounds checks and allocation size calculations, in various common media codecs. This would suggest that the exploit forces malloc to allocate an undersized buffer. There are various standard techniques they can use to exploit a heap buffer overflow, although it’s not clear that standard techniques alone are enough, since Google have been actively researching mitigations against heap corruption vulnerabilities. It’s unclear how Zimperium’s researchers dealt with these mitigations.

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).

In the meantime, be very suspicious of MMS messages from strangers.

You wouldn’t make your website slower on purpose, would you?

Perhaps it shows a bias on my part, but I tend to assume that people want their web sites to be faster.

so I was quite surprised when I saw some code on the homepage of a major high street retailer, which deliberately slowed down visitors to the site.

This wasn’t just a rate-limiting thing. It’s a proof-of-work algorithm – you have to earn the right to visit their site.

Continue reading

Wireshark: Tools versus Weapons

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.

Continue reading

Solve Memory Leaks by Not Solving Memory Leaks

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).

Or at least, that’s the theory.

Continue reading

Advanced Squeryl/Play Integration

There’s a question on Stack Overflow about how best to integrate Squeryl and Play.

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.

So, for example, if you have code like this:

def sendAsteroid = Action { req =>
  import org.squeryl.PrimitiveTypeMode._
  import DinosaurSchema._
  inTransaction {
    val cretaceousDinosaurs = from(dinosaurs)(d => where(d.era === "Cretaceous") select(d)).toList
    Async {
      Akka.future {
        for (dinosaur <- cretaceousDinosaurs.par) {
          dinosaur.extinct = true
          dinosaur.save
        }
        Ok("All cretaceous dinosaurs killed")
      }
    }
  }
}

Then your code won’t work the way you expect.

Continue reading