Usually when a developer has designed an application that relies on expected “state” or limited content formation, or does not accurately or adequately handle erroneous data a malicious user can “fake” the “content” in such a way that errors occur.
There are several different “major” types of exploitation:
A “buffer overrun” is one of the more common types of problems. A buffer is a pre-allocated area for storing temporary data. It is usually used to quickly read information from “content” and perform activities based on a predetermined structure. Sometimes the data is too big to fit within the space he set aside to work with it (the buffer) and an “overflow” (“overrun”) occurs, effectively executing the excessive amounts of data by passing them into the executable space of the system. In some cases this can execute machine code directly – which can do pretty much anything to or on your computer. Code Red is an example of this type of virus.
Another common method of exploitation is to use the default/designed behavior of something in a malicious way. Scripting is the poster child for these types of exploits. Basically, a malicious user will “test the limits” of the exploit by using its native behavior and internal abilities against the user. ILOVEYOU is a good example of this one, since it used native objects in vbscript to impose its way into the address book to send itself out again.
Some applications are authored in a way that they can read several types of content. Microsoft Word, for example, can read Word Documents, RTF Documents, HTML, XML, and a host of other formats. For applications like this a common exploit is to set the actual “content” of the data/file to something with greater abilities other than either the file extension or the “content-type” header. Many times the application that interprets these files will correctly “sort out” the appropriate content type, but sometimes at the expense of whatever security measures were designed in (like “do not run macros at startup”).
When someone discovers a design flaw in an application they can usually submit that information to the vendor to have it corrected. Unfortunately, most vendors could care less until their is a “reasonable exploit” that demonstrates that the flaw could be used to infiltrate the system or gain access that should not otherwise be possible.
The people that find out how those applications flaws work – and create the initial exploit from that information, put a lot of time and energy into them. Typically, their only reward for having devoted the time and energy towards it is a “mention” by the vendor along the lines of “a special thanks to so-and-so for pointing out this oversight”. Consequently, they often make their exploits public in order to obtain more recognition for their devotion to the bug. For an application that has a *lot* of users – like Internet Explorer – there will always be people that do not install the patches. And as long as they don’t, they will be vulnerable to future exploits based on the original versions made public.
- Exploit –> Virus
Most exploits are not made until after the ability to exploit the flaw is public knowledge. By this time, the vendor has likely produced a patch that eliminates the exploits effectiveness. However, since the exploit has been made “publicly available” it is generally not long at all before some form of virus is made to utilize the discovered exploit.
- Patch =/= Virus
There have been methods (linked above) to disable most of the common Outlook/Outlook Express viruses for over a year (in some cases *several* years). The reason why some users are still vulnerable? They don’t bother to install the patches. Usually they wouldn’t know how to get them if they even knew they were there. Please, if you are going to use a computer, keep your software up to date!