Your buffer overflow example illustrates the point. What is being over-written into the host's execution area? Answer: code/data/1's and 0's from the data file. Having never written a buffer overflow attack, I'll take your word that it's "very, very hard to do for anything but the simplest functionality". However, the size of that resulting code isn't really the point. The point is that arbitrary code is being run.
From: Andrew S. Baker [mailto:asbz...@gmail.com] Sent: Monday, April 16, 2012 1:28 PM To: NT System Admin Issues Subject: Re: Whitelisting >>Data is code. Code is data. They're both strings of 1's and 0's. No, they are most certainly not the same. >>The only difference is what is interpreting that string. And that's a huge difference. >>If data is data, how is it able to cause winword.exe to download a payload? Well, here's an oversimplification of how buffer overflows work: 1. An executable opens up a data file for manipulation 2. Because the input buffer is not adequately validated, the data (which is larger than the area allowed by the buffer), ends up overwriting a critical area of the host executable's execution area with new 1s and 0s. 3. The code which should normally execute at the conclusion of the data input is now replaced by some code stub which will do what the attacker wants. 4. This allows the host executable to now do something else than originally intended (or crash, which is what happens more often than not) Now, while this might seem like it gives one the completely co-opt the functions of the host executable for ones own purpose, in practice, this is very, very hard to do for anything but the simplest functionality. If you overwrite too much code, you'll just cause the host to die, which is essentially a DoS attack. Instead, the common practice is to use this limited area that was overwritten to call down a more robust piece of malware to get more malignant work done. (Or, alternately, to make use of already installed executables where that might make sense.) WinWord.exe, in our example, can be induced to download a payload because it was legitimately opening a data file which corrupted a portion of its application space because it did not properly validate its buffer space and thus protect itself. The initial action (File Open) is caused by a human. The DATA did not execute, but allowed for the laying down of CODE which could be executed. More detailed analysis can be found here: * http://en.wikipedia.org/wiki/Buffer_overflow * http://www.windowsecurity.com/articles/analysis_of_buffer_overflow_attacks.html * http://searchsecurity.techtarget.com/news/1048483/Buffer-overflow-attacks-How-do-they-work ASB http://XeeMe.com/AndrewBaker Harnessing the Advantages of Technology for the SMB market... On Mon, Apr 16, 2012 at 12:54 PM, Crawford, Scott <crawfo...@evangel.edu<mailto:crawfo...@evangel.edu>> wrote: Data is code. Code is data. They're both strings of 1's and 0's. The only difference is what is interpreting that string. If data is data, how is it able to cause winword.exe to download a payload? From: Andrew S. Baker [mailto:asbz...@gmail.com<mailto:asbz...@gmail.com>] Sent: Monday, April 16, 2012 11:30 AM To: NT System Admin Issues Subject: Re: Whitelisting Because it is data. Data doesn't make calls. Code does. That's been the gist of the argument from the very beginning. ASB http://XeeMe.com/AndrewBaker Harnessing the Advantages of Technology for the SMB market... On Mon, Apr 16, 2012 at 12:25 PM, Crawford, Scott <crawfo...@evangel.edu<mailto:crawfo...@evangel.edu>> wrote: Why does the code that is spawned need to download some payload or use existing files? Why can't it make its own win32 calls? From: Andrew S. Baker [mailto:asbz...@gmail.com<mailto:asbz...@gmail.com>] Sent: Monday, April 16, 2012 10:26 AM To: NT System Admin Issues Subject: Re: Whitelisting Here's one typical scenario: * WinWord.exe has a a buffer overflow vulnerability. * WinWord.exe is a whitelisted app, so the vulnerability can be exploited. * Bad guy creates a hand-crafted data file that takes advantage of the buffer overflow vulnerability * User opens bad data file, which exploits the vulnerability In a traditional environment, the exploit of the vulnerability would likely include the uploading or installation of some files to the exploited machine for the purpose of controlling it more directly. In an environment that makes use of whitelisting technology, the code that is spawned by the exploit (either because it is embodied in the bad data, or because it is downloaded from some remote server) will be unable to run -- because it is not an approved application/code. This is a key benefit of whitelisting. Now, if the malware exploit only attempts to make use of existing files (CMD, etc) then these executions will be subject to whether or not they are approved from a whitelisting perspective, but the scope of the exploit is still greatly reduced. (Read Only or Blocked Attack vs full system compromise) ASB http://XeeMe.com/AndrewBaker Harnessing the Advantages of Technology for the SMB market... On Mon, Apr 16, 2012 at 11:12 AM, James Rankin <kz2...@googlemail.com<mailto:kz2...@googlemail.com>> wrote: Ah yes, I recall this debate before. So it's not that if you used a Word exploit, for example, you could get winword.exe to do bad stuff under the context of that process - it would have to be remote code execution under its own badapp.exe - which even if you called it winword.exe would get caught by a hash value rule or check for signed code, am I thinking along the right lines? On 16 April 2012 15:54, Andrew S. Baker <asbz...@gmail.com<mailto:asbz...@gmail.com>> wrote: Yes, but if the bad data is used to perform a buffer overflow so that custom *code* can be executed to do nefarious acts, then that last step will fail because the custom malicious code is not authorized to run -- even in a zero day. No, it doesn't solve every last malware issue known to man, and there can be some management overhead depending on the implentation, but it addresses more issues than blacklisting does, and does so more effectively. Of course, we've been saying the same thing for a while here: http://www.mail-archive.com/ntsysadmin@lyris.sunbelt-software.com/msg72561.html http://www.mail-archive.com/ntsysadmin@lyris.sunbelt-software.com/msg106004.html ASB http://XeeMe.com/AndrewBaker Harnessing the Advantages of Technology for the SMB market... On Mon, Apr 16, 2012 at 10:28 AM, James Rankin <kz2...@googlemail.com<mailto:kz2...@googlemail.com>> wrote: Agreed, if you've got a malicious Word document that exploits a flaw in MS Word itself, then the only defence is good patching or some other form of exploit detection. If it's a zero-day, then there's probably nothing except exploit detection. Don't want to plug it too much but AppSense Application Manager does a good job of detecting execution beyond the "expected" capabilities of an application, but I've never been able to test it much beyond the types of things like malicious PDFs with Java exploits or exploits that call out to malicious dll files. Wonder how much work it would be to craft an Office document that tries to exploit a vulnerability to see if it can stop this sort of vector as well? On 16 April 2012 15:19, Alex Eckelberry <al...@eckelberry.com<mailto:al...@eckelberry.com>> wrote: >But, if we ever get to a world where whitelisting is the predominant >means of execution control, the bad guys will, out of necessity, be >relegated to exploiting flaws in applications through data files. I don't understand how you can have an exploit in a data file resulting in anything else but code execution. Data itself is harmless; it's the executables that cause harm. There will always be code executed, in some form or another (unless I'm misunderstanding your point). Alex From: Crawford, Scott [mailto:crawfo...@evangel.edu<mailto:crawfo...@evangel.edu>] Sent: Monday, April 16, 2012 12:25 AM To: NT System Admin Issues Subject: RE: Whitelisting Possibly...even probably. But, if we ever get to a world where whitelisting is the predominant means of execution control, the bad guys will, out of necessity, be relegated to exploiting flaws in applications through data files. A scanner that looks for signatures of exploits in files will be a useful tool. Assuming of course, all applications aren't secure. Sent from my Windows Phone ________________________________ From: Andrew S. Baker Sent: 4/15/2012 1:08 PM To: NT System Admin Issues Subject: Re: Whitelisting You can't. :) ASB http://XeeMe.com/AndrewBaker Harnessing the Advantages of Technology for the SMB market... On Sat, Apr 14, 2012 at 1:24 PM, Rankin, James R <kz2...@googlemail.com<mailto:kz2...@googlemail.com>> wrote: How do you blacklist all possible bad data files? ------Original Message------ From: Crawford, Scott To: NT System Admin Issues ReplyTo: NT System Admin Issues Subject: RE: Whitelisting Sent: 14 Apr 2012 18:02 A combination is needed. Whitelisting for traditional executable code and blacklisting for data files that exploit vulnerable white listed applications. -----Original Message----- From: Alex Eckelberry [mailto:a...@eckelberry.com<mailto:a...@eckelberry.com>] Sent: Saturday, April 14, 2012 10:10 AM To: NT System Admin Issues Subject: Whitelisting I'm curious, what's the general feeling about about whitelisting? As a former AV guy, I tend to prefer blacklisting, but I'm seeing signs things might be changing. Thoughts? ~ 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 listmana...@lyris.sunbeltsoftware.com<mailto:listmana...@lyris.sunbeltsoftware.com> with the body: unsubscribe ntsysadmin ~ 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 listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin
