XTS vs. Undiffused CBC. The issue here is malleability. Both XTS and CBC prevent an attacker from learning information about encrypted data. However, neither one completely succeeds in preventing an attacker from tampering with encrypted data.
However, it's arguably easier to tamper with an (undiffused) CBC ciphertext than it is to tamper with an XTS ciphertext. Let's say that an attacker happens to know some message says
"blah blah Give Alice \$400 ... blah blah blah".
If this message is encrypted using CBC, the attacker can tamper with the ciphertext in such a way that it will now decrypt to
"blah blah !^%@^^ Give Alice \$800 blah blah blah"
The \$400 has become \$800. This is what your quote about "AES-XTS prevents an attacker from changing one specific bit in a data unit" refers to. Here I write !^%@^^ to indicate that the previous 16-byte block will become gibberish once decrypted, and this gibberish will be beyond the attacker's control.
On the other hand, using XTS prevents this attack. The attacker can corrupt a message by turning any 16-byte block into random gibberish, but he will not be able to have the same degree of control as he did in the CBC example.
But Microsoft decided not to use XTS anyway. The reason is that the ability to corrupt a 16-byte block could still be damaging. Here's the quote from the paper dchest linked:
For example, there could be
a configuration file (or registry entry) with a value that, when set to 0, creates a security
hole in the OS. On-disk the setting looks something like "enableSomeSecuritySetting =
1". If the start of the value falls on a 16-byte boundary and the attacker randomizes the
plaintext value, there is a $2^{16}$ chance that the first two bytes of the plaintext will be 0x30
0x00 which is a string that encodes the ASCII value ’0’.
(This quote is referring to the LRW tweakable cipher, but the XEX tweakable cipher used in XTS has the same problem).
Adding a diffuser. Using a diffuser is Microsft's solution to this problem. The idea here is to "mix" the plaintext up before encrypting it so that an attacker can't change \$400 to \$800 --- meddling with part of the ciphertext will change almost the entire plaintext, not just small parts of it.
This sounds good, but there's a catch: No one actually knows if Microsoft's diffuser actually is secure. To my knowledge, it hasn't received any published formal analysis from cryptographers. This means you should be skeptical about relying on it. Microsoft acknowledges this:
On the disadvantage side, the diffuser is a new unproven algorithm, and this inevitably
leads to questions. Without extensive public scrutiny and analysis of an algorithm, there
is a justified skepticism about its security. People are reluctant to trust new algorithms.
So why did we choose this option anyway? In our final analysis, we decided this was the
better choice for our product. The performance gain over the alternatives was important
enough to outweigh the disadvantages of a new diffuser algorithm. Time will tell whether
we made the right choice.
The bottom line.
XTS is less malleable than undiffused CBC. However, CBC+Diffuser is probably less malleable than XTS, at least for practical purposes.
An important aside.
Neither CBC nor XTS were designed to be non-malleable. Ensuring that ciphertexts are not tampered with is a separate problem, one that should be solved by using Message Authentication Codes (MACs), such as HMAC-SHA256. The reasons MACs aren't typically used for full-disk encryption algorithms are (1) performance issues and (2) using a MAC requires storing extra information with the ciphertext, which makes adding it transparently a bit tricky.
A middle ground between MACs and diffusers would be to use a wide-block encryption mode, such as CMC, EME, or HEH. You can think of these as having a "built-in" diffuser, that makes them non-malleable. Unlike Microsoft's diffuser, these algorithms have formal security definitions and peer-reviewed mathematical proofs. They are secure under the assumption that AES is secure. Microsoft opted not to use these because of (1) performance issues and (2) patents.
