> You're less likely to blow that up than GCM.
Do you have a pointer where I can read about traps of GCM?
I don't know the best summary, but the broad strokes are that nonce reuse both destroys confidentiality and allows recovery of authentication keys --- this is an extraordinarily common problem and one attackers can sometimes induce --- as does truncating the GCM MAC, and, if you don't have hardware support for GCM (ie, x64 CLMUL), the table-based version is timable.
CBC mode is also susceptible to attacks based on predictable IVs. But again, CTR is susceptible to a sort of isomorphic class of bugs related to repeated nonces --- as, of course, is GCM, which you mention before; GCM not only inherits CTR's brittleness with respect to nonces but also fails in spectacular new ways with them.
Arguably, if you're going to have to build your own cryptosystem from primitives (don't do this), you have the best chance of success with random-IV CBC mode and HMAC-SHA2 in an EtM configuration. You're less likely to blow that up than GCM.
The research here is in detecting instances of the well-understood CBC padding oracle flaw. A new measurement technique that surfaced a whole bunch of new instances of heap overflows in server software would be an important contribution, in the same way this is.