In another question's answer, D.W. wrote:
Make sure there is authenticity protection for the encrypted data (e.g., encrypt and then sign/MAC): you will need both confidentiality and authenticity protection. A very common error is to encrypt but fail to sign; this error can introduce subtle security problems
What exactly are those security problems?
A good example is the flaw on CBC, demonstrated within SSL and in particular for password recovery in a IMAP-over-SSL setup. See for details. Briefly speaking, SSL has a MAC, but a small part of it was doing things with the received encrypted data after decryption but before verifying the MAC. Namely, the receiving system was decrypting the data, checking that the padding was correct, reporting an error to the peer if that was not the case, and then only checking the MAC. The error message was different if the MAC was wrong. So the receiver (the server, in the case of the IMAPS password recovery) was leaking a single bit of information about whether the padding found after decryption was correct or not. It so happens that SSL uses a padding which is similar to the one described in PKCS#5. Details are subtle (but not mathematically hard, once you understand that XOR is commutative and associative) but it allowed the attacker, by modifying a few well-chosen bytes, to guess one by one the plain data bytes. Assuming a regular connection attempt with identical contents (typically, an Outlook Express which checks the server for new mail every 5 minutes), the attacker had 1/256 chance of guessing a new byte at each connection. At the end of the day, voila! a full password.
This case shows what may happen in the presence of active attackers and no MAC, even when the "no MAC" part is very transient; because SSL has a MAC, only it was checked too late in the process. The correction is to always check the MAC, regardless of whether the padding was good or not, and to report bad padding and bad MAC with the same error code (you have to check the MAC, because not doing it when the padding is wrong may make the server respond a bit too fast in that case, leaking the bit of information through timing). Without that correction, the server leaks some information through its behavior, be it a distinct error message or even a slight delay (or lack thereof) when responding. That's a single bit at each attempt. Yet it suffices to mount a password-recovery attack.
That attack was published in 2002. Yet, in 2010, the same bug was still present in how ASP handles encrypted cookies, allowing an active attacker to hijack a protected session in less than an hour. The attack was demonstrated as practical in 2002; in 2010, it was demonstrated as actually practiced in the field.
We do not have an exhaustive list of the attacks made possible by a lack of MAC. So the common wisdom is that there is no proper security against an active attacker when there is not a dedicated integrity check, and that's a MAC. The common mistake is to believe that in any given situation, attackers can only be passive. Wired and wireless communications are routinely subject to active attacks by even low-power bad guys (say, bored students in a cybercafe).
When doing symmetric encryption, the proper way to add a MAC is to use a combined encryption-and-MAC mode such as GCM or EAX. These are modes which rely on a block cipher (typically AES). There are other such modes, but some are patented; these two are believed not to be.
Signatures (as opposed to MAC) are an altogether distinct matter, in particular in their relationship with confidentiality.
