Cyber Crime Scene Investigations through Cloud Computing [pdf]
cs.uml.edu
cs.uml.edu
On a more practical note, few cloud providers are going to let their network suddenly become a massive transit space for Tor traffic.
Before this could be successfully deployed in the wild, the problem can be easily corrected.
With ~4k relays (entry/exits) and ~2k bridges (pure relays of encrypted connections) and only a few hundred hostile relays, the odds of an OP's (end-user's) connection's flowing through both a hostile entry node and a hostile exit node are infinitesimal.
Let's say you add 400 ORs to the network. Let's further assume no one in the privacy-conscious, some would say paranoid, Tor community notices this unexplained 10% spike in entry/exit nodes. Your odds of compromising any given Tor circuit (connection) are a compound probability: P(A and B) = P(A) * P(B). In this case: .1 * .1 = .01, or approximately 1%.
When you add to the fact that the network automatically tries to route to entry and exit nodes in different countries, the chances of compromising the network in this fashion are virtually nill.
Everyone in the Tor community has known this attack has been possible, which is why the network growth metrics are watched closely. If any shenanigans are detected, the authority is prepared to add a notion of OR trust to the directory file.
In reply to s_q_b: Amazon actually hosted this guy's demonstration, so at least one good cloud provider has in fact done this. Additionally, if you time your attack correctly and don't have persistent objectives, then it's pretty much moot that the spike is obvious because who checks the total amount of nodes frequently while surfing? Finally, if you do have persistent objectives, then you could mask it by introducing nodes by the dozen or so randomly spaced over a year or two.
Edit: just to clarify: Not my paper. No one has commented to that effect yet, but I just realized that that could be a conclusion drawn. I've only done some analysis on this type of attack.