I have two questions regarding the Block Cipher Modes:
Personally I like the modes that support integrity checking and authentication, e.g. GCM, as they only require one key, and are not vulnerable to changes in the cipher text. One particular important problem area is padding oracle attacks, which are much more common than people seem to admit.
Note that GCM/AES is - just like CTR - a block cipher in stream cipher mode; Basically GCM consists of a GMAC and CTR combination.
GCM is supported by XML encryption v1.1 (XML encryption by itself is very vulnerable to padding oracle attacks). There is also https://www.rfc-editor.org/rfc/rfc5288 which describes the use in TLS and https://www.rfc-editor.org/rfc/rfc5084 which describes the use in CMS.
GCM seems to have some support, e.g. Java 8 introduces GCM in the standard Java Runtime. For Java 7 and below it is required to use an external provider such as Bouncy Castle.
There is no "best" mode of operation, just modes more or less useful in different situations.
CBC-mode requires an initialization vector which is unpredictable by the adversary (preferably random), especially if this adversary can mount a chosen plaintext attack. Up to TLS 1.0 (i.e. also in SSL 2.0 and 3.0), CBC was used with a "use last block of previous message as IV", and this is obviously not unpredictable if there is some time between the messages. TLS 1.1 fixes this by using a random per-message IV.
This problem can be avoided by implementations (without violating the protocol) by sending an empty message (which still gets padded to at least a full block) directly before any real message (i.e. after the application decided the content of the real message), and this is what OpenSSL does for quite some time. (It helps only on the sending side, not the receiving one, though.)
CTR mode requires that the initialization vector is non-repeating for all uses of the same key, as identical IVs give an identical key stream (which is then XORed with the message) - the same is valid for OFB mode.
I think the attack on CBC that you're referring to is a known-plaintext attack where an attacker can manipulate a plaintext by adjusting the previous block of ciphertext. But this same sort of attack also applies to CTR.
[edit] I misinterpreted the OP's referenced to a CBC attack. The one I describe here allows intelligently modifying plaintext by modifying the ciphertext. This is a valid attack to be concerned about and applies to both CBC and CTR, so I will leave it as a part of the analysis of the modes of operation, but it is not the attack mentioned by the OP. [/edit]
CTR is a good mode overall, but it must be used in the right context given that it is a stream cipher. You should not use it in a case where you will be re-encrypting the same data with the same key and IV (for example if you're doing disk encryption). In practice, this often means that you should only use it if you're willing to completely re-encrypt data every time it's edited/saved/transmitted.
The newer block mode XTS is an interesting mode because it does away with the ability to modify the plaintext by altering the ciphertext (like mentioned above), and it also allows for single-block encrypt/decrypt access like ECB and CTR. The disadvantage to it is that it has the same information leakage that ECB and CTR have, namely editing/re-saving ciphertext leaks exactly which blocks were modified. In practice, however, I don't think many people are concerned by that.
Right now there is no official "best" mode, but it seems like there is a heavy favoring of XTS due to the fact that plaintext is not malleable and that it is well-suited for many uses, both of CBC's and CTR's domains. Disk encryption products have switched en masse to XTS recently. I don't think network communications has, though.
For what it's worth, in the book Practical Cryptography (first edition) by Niels Ferguson and Bruce Schneier they made a comment that CTR was "their personal favorite" (paraphrased quote) mode of operation at the time. That was written in about '03, though, and I don't know if that comment was preserved for the second edition of the book; it was made long before XTS came around.
