Scott, Your response points out things that I already pointed out in my response. Yes, there are specific scenarios where whitelisting does not prevent an attack. Even then, it still affords additional opportunities to mitigate exploitation of the vulnerability. Additionally, there are many other scenarios where whitelisting addresses a weakness of blacklisting.
So you still come out ahead. Please note my comments about vendor facilitation of granular feature control to mitigate the types of problems that you are focusing on. Now, let's look at how the vulnerabilities you mention are actually exploited. - http://en.wikipedia.org/wiki/Windows_Metafile_vulnerability - http://isc.sans.edu/diary.html?storyid=992 - http://www.microsoft.com/technet/security/bulletin/ms06-001.mspx By getting someone to open up a specially crafted data file (via web, email, file share, etc), you can cause the primary application to spawn your executable (which is hidden in the "data" file) -- typically with all the rights of the spawning app. Now, depending on how such an application is initiated, it may not spawn as a child process, but as its own process. If it spawns as a child process, then whitelisting may or may not help. But, as its own process, it would fail to be initiated -- even in a zero day scenario for which no signatures exist. Even if this is only in 50% of the zero-day situations, you're still protected to a much greater degree than via signatures alone. *>>Antimalware signatures are generally produced much more rapidly than an application patch. So, while a zero day flaw may take a week (optimistic) to patch, the AV vendors could be blocking all .txt files containing the offending string of bits.* Which doesn't take into account all the effort that malware writers put into their "work" to ensure that offending string of bits is obfuscated. Even if it takes the signature writers a mere 24 hours to: - figure out all the combinations of "bad bits" - test and validate the fix - make the fix available to their distribution mechanisms - get your systems to pick them up That's still a long time for a zero-day infection to do its work. And, having worked with a number of AV vendors on zero-day scenarios, 2-3 days is not unreasonable for reverse engineering a good exploit. Where does that leave your systems which are only relying on a list of bad things to block? *>>Agreed…for the time being. But, if we were to flip a magic switch and swap to a predominantly white-list based environment, the most common exploitation vectors would switch to exploiting white-listed .exes through buffer overflows or other methods of tricking an .exe to doing more than displaying data in a data file.* I'm not sure where you have gotten this idea that buffer overflow and "executable" data exploits involve making the parent application do new tricks. All they do is get the parent application to run new code of the attackers choice, and in many cases, that code is subject to running in its own environment -- thus, blockable in a whitelisting scenario. I've experienced several examples of this during my testing of what later became Cisco's CSA product, and eEye's Blink! Here's a good article to read: http://www.intelligentwhitelisting.com/blog/problem-vulnerable-whitelisted-application-part-ii *ASB *(My Bio via About.Me <http://about.me/Andrew.S.Baker/bio>) *Exploiting Technology for Business Advantage...* * * On Mon, Jan 31, 2011 at 7:12 PM, Crawford, Scott <[email protected]>wrote: > Inline, but here’s some opening comments J > > > > White-listing .exes does nothing to stop attacks like .wmf and .jpg > vulnerabilities below. > > > > > http://www.symantec.com/business/security_response/attacksignatures/detail.jsp?asid=21526 > > > http://www.symantec.com/security_response/writeup.jsp?docid=2004-091516-5119-99&tabid=2 > > > > While these may be currently patched and/or low risk, I think they server > to illustrate my point. Note that AV signatures detect the badness in them > before Microsoft patched the offending executable. Also note that under all > but the most restrictive white-listing campaign, the code that processes > .wmf and .jpg would be allowed. > > > > Again, please don’t misunderstand me. I’m not saying white-listing is > without its advantages. I’m simply saying that it’s not a solution to stop > malware. Impair it? Yes. Stop some of it? Yes. But, the primary reason it > stops some and even most current malware is because it’s not very popular > yet. > > > > *From:* Andrew S. Baker [mailto:[email protected]] > *Sent:* Monday, January 31, 2011 2:47 PM > > *To:* NT System Admin Issues > *Subject:* Re: Intel developing security 'game-changer' > > > > *>>There are MORE good files that I want to use than bad that I want to > block. * > > > > Except that most of those good files won't get executed if you stop a more > limited number of other executables from launching. > > > > My concern is infected data files that are associated with a white-listed > .exe. > > > > You don't necessarily have to track every version of every known DLL that > might ever get executed, if you can simply track the far more limited number > of executables that would spawn them. > > > > Understood > > > > It would appear that you're looking at whitelisting in a very different way > than is typically implemented. What is your understanding of how a > whitelisting solution would need to work? > > > > Yes, I am becoming aware that I’m looking at it very differently J. That > is basically my point. The way it’s typically implemented is to specify an > allowed list of executables using multiple ways of compiling that list – > publisher, path, hash, filename, etc. This is basically the only practical > way it can work. However, to be **truly* *stop all malware from executing, > it would also have to include all documents/data files that a user would > want to use. > > > > > > *>>**If there’s a chance that said application will make a mistake, then > we also need something signature based to block the bad bits.* > > > > Except that the scenario you're presenting is exactly what we call Zero Day > attacks. Vulnerability is discovered in an approved app (no matter how you > chose to identify "approved app") and it gets exploited. How is a signature > helping there when the attack is new? > > > > Antimalware signatures are generally produced much more rapidly than an > application patch. So, while a zero day flaw may take a week (optimistic) to > patch, the AV vendors could be blocking all .txt files containing the > offending string of bits. > > > > > > If the vulnerability is one that requires no new executables, then a > zero-day attack is equally damaging to a whitelist or blacklist approach. > > > > If the vulnerability is one that spawns a new executable, then a zero-day > attack is not effective in a whitelist scenario, but just as damaging as > always in a blacklist scenario. > > > > I address the need for vendors to allow features and functionality to be > enabled or disabled independently (in the very next paragraph) > > > > Right. The ability to turn off javascript/macros in Word, Reader, IE, etc. > is certainly a beneficial addition, but it doesn’t prevent other forms of > malware that may be present in a .doc or .pdf, just the malware that > exploits the built-in execution engine. > > > > , which would provide even more security. In the meantime, blacklisting at > the host level as the primary means of protection is a game of increasing > risk with diminishing returns... > > > > Agreed…for the time being. But, if we were to flip a magic switch and swap > to a predominantly white-list based environment, the most common > exploitation vectors would switch to exploiting white-listed .exes through > buffer overflows or other methods of tricking an .exe to doing more than > displaying data in a data file. > > *ASB *(My Bio via About.Me <http://about.me/Andrew.S.Baker/bio>) > *Exploiting Technology for Business Advantage...* > > > > > > On Mon, Jan 31, 2011 at 2:36 PM, Crawford, Scott <[email protected]> > wrote: > > “Application whitelisting is a good idea, because for every environment, > there are less items that fall into the “*known good*” category than bad > code that you don’t want to run.” > > > > This assumption simply isn’t true. Data = 1’s and 0’s = code. There are > MORE good files that I want to use than bad that I want to block. If there > was some magic bullet that ensured “data” files could never contain > executable bits, then I would agree whole heartedly. But, I don’t believe > such bullet will ever exist. Therefore data = 1’s and 0’s = code and its up > to the whitelisted .exe to interpret them correctly. If there’s a chance > that said application will make a mistake, then we also need something > signature based to block the bad bits. > > > > *From:* Andrew S. Baker [mailto:[email protected]] > *Sent:* Monday, January 31, 2011 12:25 PM > > > *To:* NT System Admin Issues > *Subject:* Re: Intel developing security 'game-changer' > > > > Here are my full thoughts on the subject, as a security mechanism: > > > > > http://home.asbzone.com/ASB/archive/2010/05/10/it-s-time-to-re-evaluate-host-based-security.aspx > > > > No, it is not a panacea, because no security mechanism ever is. Yes, there > are drawbacks, but focusing on these technologies will provide a bigger bang > for the buck and allow us to mitigate the weaknesses sooner. Either way, > your ROI is greater in most scenarios which use whitelisting vs > blacklisting. > > > > Also, check out the following: > http://www.schneier.com/blog/archives/2011/01/whitelisting_vs.html > > > > > > *ASB *(Find me online via About.Me <http://about.me/Andrew.S.Baker/bio>) > *Exploiting Technology for Business Advantage...* > > > > > > On Mon, Jan 31, 2011 at 12:48 PM, Crawford, Scott <[email protected]> > wrote: > > “No one here has suggested panacea” > > > > Perhaps not, but that’s not my perception. I see lots of statements like > “I’m still of the opinion that the only real solution is white-listing. - > MBS” Maybe I’m misreading that, but that hints at a panacea and I’m simply > saying that it’s not. > > > > All of your other points – I agree. > > > > *From:* Andrew S. Baker [mailto:[email protected]] > *Sent:* Wednesday, January 26, 2011 4:35 PM > > > *To:* NT System Admin Issues > *Subject:* Re: Intel developing security 'game-changer' > > > > No one here has suggested panacea, but consider how effective it would be > in a white-listing environment to add most apps to the list in the event of > a zero-day to an EXISTING app. You wouldn't have to do anything for an app > that wasn't already allowed in your environment. > > > > It is akin to the change in firewall rule-set made in ages gone by from > Allowed-by-Default to Denied-by-Default. > > > > Likewise, look at all the environments that have moved towards some form of > locked down user desktop and see how much of a benefit has resulted. > > > > Reducing problems by 50-80% off the bat, with little overhead, is always > desirable. > > > > *ASB *(My Bio via About.Me <http://about.me/Andrew.S.Baker/bio>) > *Exploiting Technology for Business Advantage...* > > > > > > On Wed, Jan 26, 2011 at 5:03 PM, Crawford, Scott <[email protected]> > wrote: > > My point is that neither signatures, nor white-listing are a panacea. The > fact that we’ve been sig based for so long while malware continues to be > effective leads many to think that white-listing would solve all our woes. > I’m simply saying that many **current** vulnerabilities circumvent a > white-list so it can’t be a panacea…unless of course you white-list each > individual data file. > > > > *From:* Andrew S. Baker [mailto:[email protected]] > *Sent:* Wednesday, January 26, 2011 1:55 PM > > > *To:* NT System Admin Issues > > *Subject:* Re: Intel developing security 'game-changer' > > > > Just as network anomaly detection devices don't eliminate the use of > signatures, whitelisting solutions can still make use of several mechanisms > for avoiding bad stuff. > > > > It is the complete RELIANCE on signatures that is troublesome. > > > > Oh, and btw, I try to avoid Adobe Acrobat altogether. There are plenty of > viable alternatives at the moment... > > > > *ASB *(My Bio via About.Me <http://about.me/Andrew.S.Baker/bio>) > > *Exploiting Technology for Business Advantage...* > > > > > > On Wed, Jan 26, 2011 at 2:51 PM, Crawford, Scott <[email protected]> > wrote: > > Unless you’re going to white-list every doc/jpg/pdf/mp3 you’re going to > open, that’s not a panacea either. Documents = 1’s and 0’s = code. The only > difference is what layer its executed at. Assume you white-list > AdobeReader.exe. The next time a flaw is found that is exploited through a > malformed PDF, it will march right through your white-list. > > > > *From:* Michael B. Smith [mailto:[email protected]] > *Sent:* Wednesday, January 26, 2011 1:38 PM > > > > *To:* NT System Admin Issues > > *Subject:* RE: Intel developing security 'game-changer' > > > > I’m still of the opinion that the only real solution is white-listing. > > > > But that raises its own set of issues. > > > > Regards, > > > > Michael B. Smith > > Consultant and Exchange MVP > > http://TheEssentialExchange.com > > > > *From:* Andrew S. Baker [mailto:[email protected]] > > *Sent:* Wednesday, January 26, 2011 2:35 PM > > *To:* NT System Admin Issues > > *Subject:* Re: Intel developing security 'game-changer' > > > > Since a whole lot of allegedly legitimate software acts just like malware, > they'd have their work cut out for them. > > > > Try installing a host-based IPS on your system in monitoring mode, and look > at what it would block -- and why. > > > > There are certain classes of zero-day that can be blocked by software or > hardware. There are others that cannot be, simply because of what passes > for functionality these days. > > > > Oh, and I agree with Ben and Jonathan... > > > > *ASB *(My Bio via About.Me <http://about.me/Andrew.S.Baker/bio>) > *Exploiting Technology for Business Advantage...* > > > > > > On Wed, Jan 26, 2011 at 1:47 PM, Sean Martin <[email protected]> > wrote: > > Most important statement.... > > > > "*If Intel has hardware technology that can reliably stop zero-day > attacks, that would be a huge win in the war against malware," Olds said. > **"The key is that it's reliable. It has to have the ability to discern > legit software from malware**. But if they can pull this off, it would > give them quite a competitive advantage **vs. > AMD*<http://www.computerworld.com/s/article/9204580/AMD_could_better_fight_Intel_with_new_CEO_> > *."* > > > > - Sean > > > > On Wed, Jan 26, 2011 at 9:37 AM, David Lum <[email protected]> wrote: > > What say you, Alex, et all. > > > > > http://www.computerworld.com/s/article/9206366/Intel_developing_security_game_changer_?taxonomyId=85 > > > > Hype? > > *David Lum** **// *SYSTEMS ENGINEER > NORTHWEST EVALUATION ASSOCIATION > (Desk) 503.548.5229 *// *(Cell) 503.267.9764 > > > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
