The hacker registered for the Hotmail address and had Gmail send a password reset for the Twitter employee's Gmail account to what was now the hacker's Hotmail account. With the new password, the hacker gained access to the Twitter employee's Gmail account. Using information found in the employee's e-mail, the hacker was able to acquire personal information about the employee and data to exploit Twitter's own network. TechCrunch has an excellent step-by-step account of the hack.
These actions took a lot of (successful) guessing and the reliance on default human behavior. All in all, this is one of the most interesting hacks I've read about in a long time. It makes the Sarah Palin e-mail account hack seem like child's play (which it was).
These two scenarios reveal the difficulty of planning for and combating chained exploits. In the case of net/tun, the developers of the program might need to rewrite the code such that the compiler doesn't remove the important IF-THEN statement. For sure, the developers of the compiler need to rewrite their code, lest it create security bugs in a future application.
The second exploit type generated a lot of discussion among my friends and co-workers. Specifically, we focused on how to prevent an old, now long-ignored e-mail account from being exploited by hackers. Simply preventing e-mail name reuse isn't an efficient application of available resources.
One bright friend thought of using an automated mechanism to help the first e-mail host (Gmail) to communicate with the second (Hotmail, in the example) to determine how long it has been since the second account was used. If the time period exceeded the first host's expected terms of service, the host would not send a password reset notification to the older e-mail address.
The brainstorm of solutions went on and on, and each seemingly perfect answer was found to be riddled with exploit vectors. It ultimately came down to the ongoing problem of transitive trust. One weak link in the chain means the whole chain is broken.