It isn't against an attacker who has access to the running computer when the encrypted device is mounted as either (i) the attacker is root and it can access the encrypted device anyway or (ii) he is an unprivileged user and can be stopped with Unix's right management (i.e. user/group).
This attack is only applicable to device storing data which are reused across mounts: most file-system (e.g. ext2, reiserfs, ext3) but not swap. In some systems, encrypted device are stored in the same location than the encrypted disk containing the operating system. For those systems the attacker who can access the encrypted device, can easily modify the OS to gain access (e.g. kernel) independtly of the encrypted device.
This lack of authentication isn't a CBC flaw. Authentication isn't considered a aim of the encryption mode, so most modes (e.g. ECB, CFB, OFB) doesn't authenticate the data. To use another mode would be flawed in the same way except if they explicitly protect against forgery. Recently some modes including authentication popped up to speed up the encryption / authentication couple but as far as i know they are all patented.
In very short, encrypting with CBC is Cn=Enc(Cn-1 xor Pn) where Enc(x) is encrypting x, Pn is the nth block of plain text and Cn the nth block of cipher text. For the first block, Cn-1 is an Initial vector (aka IV) which may be public and must be unique for a given key. The decryption is Pn = Dec(Cn) xor Cn-1. See [oST81,sec 5.3] for a longer description of CBC.
If the attacker copies s blocks from the location m to n (aka [Cn,...,Cn+s-1] == [Cm,...,Cm+s-1]), Pn+1 up to Pn+s-1 will the same as Pm+1 to Pm+s-1 and Pn will likely appears random. Cn (i.e. Cm) will be decrypted as Pn = Dec(Cm) xor Cn-1 but Cm-1 and Cn-1 are different so Pn will likely appears random. Nevertheless Pn+1 = Dec(Cn+1) xor Cn = Dec(Cm+1) xor Cm = Pm+1, so Pn+1=Pm+1. So if the attacker has an idea of the content of a group of blocks in the device, he can copy them to the Nth block, thus it can choose the content of it without being detected.
As an file-system isn't designed to appears random, its content may be predictable to some extents (e.g. common directories and files, inode, superblock). The attacker may use such informations to guess the contents and do a knowledgeable cut/past. For example, an attacker knowing the location of a password file may replace a password by another one which is already known.
In the proposed fixes, the authentication is a MAC computed over the encrypted device. The MAC is HMAC[KBC97] combined with a configured hash function, preferably a well studied one such as SHA1[oST95] or MD5[Riv92]. The MAC secret key is derived from the pass-phrase via PKCS-5 key derivations ([Kal00,sec 5.1]).
The MAC generation is done when unmounting the device. The MAC is computed over all the sectors of the device and the result is appended in the device file after all the sectors.
The MAC verification is done when mounting the device. The MAC is computed over all the sectors of the device. If the result is equal to the MAC appended to the block device, the verification succeed, else it failed. The verification may fail (i) if an attacker attempted to modify the device during 2 legitimates mounts or (ii) if the device hasn't been cleanly unmounted (e.g. computer crash). It is impossible to automatically distinguish both cases with certainty. So if the verification fails, the user is notified and the mount operation may be stopped depending on configuration.
If the device isn't cleanly unmounted, the authentication of one or more cluster may fail (e.g. the super block). This case will be detected at mount time. But if an attacker forges data in the device, it will be detected only when the user read the modified data. The kernel will read the forged cluster and the authentication will fail. It may report it with a printk with a rate limitor, it isn't clean but i don't see any better way.
The authentication at mount time will detect forgery at mount time, whereas the alternative detects it only when the forged cluster is read, possibly a long time after the modification. Users may consider that it is easier to diagnose who forged it if they have a better idea of when the attack occurred.
To authenticate the whole device at mount time requires a single MAC per device, so the space overhead (typically 16 byte) is negligible compared to the device's size. To authenticate at the cluster level requires a MAC per cluster, it is significantly more but some people may consider it still negligible, especially with cheap disks.
The choice between the two mostly depends on the access pattern on the encrypted device. If the device is used for interactive purpose, the increased access latency may be unsuitable. If the access latency is important or if every block is frequently modified, to authenticate only once at mount time may be more interesting. If the user can't stand long mount operations, to authenticate at cluster level will be more suitable. As only the final user knows the type access made on his encrypted device, he should be the one able to choose between the two.
The authentication may be optionally disabled thus if an user considers the trade-off delay/security not in favor of security, he may choose to be vulnerable to this attack and disable it. Nevertheless the author thinks encrypted loop device must be secure by default.