With all the talk about the latest wave of PDF exploits in the wild,
proactive protections against vulnerabilities in common applications (MS
Office, Acrobat Reader, RealPlayer, WinAmp, Windows Media Player…) are proving
to be an effective solution for protecting users. These proactive measures
allow the vast majority of users to be protected against any and all new 0-day
exploits without going bananas over whose vulnerability it is, where to
download the latest hotfix from, whether this hotfix will prevent future
similar vulnerabilities or even introduce new ones.

 

But how can we achieve effective proactive protection against these vulnerabilities? Some protections against Buffer Overflows, Heap Overflows, Integer Overflows, etc. have to overcome some great technological difficulties.
We need to search for a different path when designing an effective proactive
solution for end users. At Panda we developed a project of proactive
protections over 3 years ago which is now known under the commercial name of
TruPrevent ("How TruPrevent Works" Part 1 and Part 2).
The second part of this technology was specifically designed to avoid these types of
0-day exploits, protecting users from the very same moment the exploit is
released and before the vulnerability is widely patched.

 

The main idea consists of establishing a behavioral profile for
software.
Basically, if we are able to establish which actions are legal and
which actions are outside of the normal behavior of an application, we can
detect potentially dangerous actions. You might think that establishing this
type of profile can be complicated, but let's go over a few examples that,
while being fairly simple, have allowed us to proactively block 100% of the
Microsoft Office and PDF exploits seen recently.

 

For example, how can we block 100% of the vulnerabilities that affect
Microsoft Office products?
If we review the malware that exploits vulnerabilities in Word, Excel,
PowerPoint, etc. we will find a common behavior which occurs when the
vulnerability is exploited: the creation of executable code in the system by
the Microsoft Office applications. Now we should ask ourselves the following
question: is it really necessary that Word, Excel, and PowerPoint should be able to create and launch executable code on the system? Is this not an atypical
behavior for these types of applications?

 

Let's think about some more examples. What applications really need to
execute cmd?
Does Adobe Acrobat need to execute cmd? NO.
Does Windows Media Player need to execute cmd? NO.
Does RealPlayer need to execute cmd? NO.

These are very simple examples but which have demonstrated their
effectiveness against many vulnerabilities during the last years. These types
of protections can be greatly enhanced with the help of event correlation
logic, which allows for establishing a baseline of application behavior,
thereby avoiding the limitation of basing decisions only on individual or point
actions.

 

Why don't we block these behaviors by default?
But the big question is "who is we?" Who is responsible for
creating a safe computing environment that does not allow these types of
vulnerabilities to run wild and spread more malware with complete immunity?
Without going into another finger-pointing war about who's fault it is (Adobe
has issued a patch even though it doesn't solve the underlying problem), "we" is the
entire computing industry, including OS and third-party vendors as well, not
only the anti-malware vendors. Fixing point-problems (patches for
vulnerabilities) without attacking the root of the problem will continue to allow
malware to prevail.


TruPrevent's Kernel Rule Engine proactively blocking a PDF exploit 

Thanks to Ismael Briones for his great contributions and continued work on vulnerability exploitation prevention.