A BHO is a DLL, in other words, a PE file. As is an OCX. These would be/should be covered by a competent whitelisting solution.
AFAIK, Javascript can't do much malicious in and of itself except crash your browser or do other weird stuff. Where it is malicious is when it can execute Windows code locally (or Mac code, if running on a Mac machine). -----Original Message----- From: Ziots, Edward [mailto:ezi...@lifespan.org] Sent: Monday, April 16, 2012 7:47 AM To: NT System Admin Issues Subject: RE: Whitelisting One of the things I see mentioned below is the malicious browser based attacks ( BHO's, Malicious JavaScript, etc etc) and that is one area of weakness I see in the whitelisting solution. Other than that I agree it’s the right way to go. Being on the other side of "Blacklisting", HIPS etc etc, it is a diminishing return over time when you have to write rule after rule to allow software to do things that aren't good coding practices, or worse, just to get the software to run. The other thing I would feel might be a weakness in the whitelisting solution, is if I allow a piece of software to run, and that software runs as a service and that service is remotely exploitable, than I can usurp the computer or any computer running that software, because I have exploited a trusted process. Again how can the whitelisting solution protect you from what you already have trusted if its flawed. Again layers of defense is still a valid argument here.. Z Edward Ziots CISSP, Security +, Network + Security Engineer Lifespan Organization ezi...@lifespan.org -----Original Message----- From: Ken Schaefer [mailto:k...@adopenstatic.com] Sent: Monday, April 16, 2012 2:24 AM To: NT System Admin Issues Subject: RE: Whitelisting > To drive the point home - If I had to choose between whitelisting > applications and blacklisting data, I'd choose whitelisting applications, > every time. Why would you have to make a choice? They are not mutually exclusive options. "To drive the point home" - those words do not mean what I think you believe they mean. > Whitelisting helps those who help themselves (corporately or individually). > Think of it as evolution in action. Those people generally don't run into problems in the first place. Digital signatures, signed kernel mode code etc. can be used to verify that software you are running is mostly legitimate. The tools already exist for whitelisting applications running on your home computer - even Windows includes Software Restriction Policies, Applocker etc, but I doubt you've implemented it - it's simply too much hassle to create a digital signature of each and every single executable you want to allow, and then restrict each and every .dll or resource file that the .exe is allowed to load into its process space, and then also ensure that every application doesn't provide some shared memory space or other way for code to end up inside the permitted process. Cheers Ken -----Original Message----- From: Kurt Buff [mailto:kurt.b...@gmail.com] Sent: Monday, 16 April 2012 2:14 PM To: NT System Admin Issues Subject: Re: Whitelisting On Sun, Apr 15, 2012 at 22:31, Ken Schaefer <k...@adopenstatic.com> wrote: > -----Original Message----- > From: Kurt Buff [mailto:kurt.b...@gmail.com] > Subject: Re: Whitelisting > > On Sun, Apr 15, 2012 at 21:50, Ken Schaefer <k...@adopenstatic.com> wrote: >>> For the SOHO end user, the vast bulk of infections are either: >>> a) exploits in existing applications (Acrobat Reader, Adobe Flash, >>> Java runtime, Internet Explorer) >>> b) social engineering attacks, where the user is convinced to run/install >>> some malware that they shouldn't. Despite code signing, users are still >>> doing this. >>> >>> How will whitelisting help the above type of user? I can't see how >>> it does - they will always have the ability to override whatever >>> recommendation the AV (or protection application) provides. >> >>Simple - they won't have to worry about "file.doc.exe" (or >>VBS|JS|JAR|DLL|etc) embedded in their emails, or the random >>executables from the various web sites either are deliberately set up, >>or have been subverted, to issue malware. Those are actually the larger >>threat, AFAICT. > > So, it doesn't help with any exploits of existing apps, browser plug ins etc. > > And if Joe User goes to AcmeSoftwareCompany.com and is persuaded that > BritnesSpearsNaked.exe is actually a legitimate file, and then tells his > WhiteListing application that it should be added to the white list, then > it'll still run. And Joe User will still be screwed. > > And if Joe User gets CheckOutDancingPigs.vbs in his email, and is persuaded > that it's from his good Nigerian Prince friend Joanne User, and runs it, and > tells his WhiteListing application that is should be added to the white list, > then it'll still run fine. > > We already have UAC, and AV, and Smart Screen, and Integrity Level warnings, > that warn users that the application might be something bad. Yet users still > allow this applications to run. With Whitelisting, you are also requiring > that the user decide what is legitimate and what is not. And users will > continue to be socially engineering into believing that malware are > legitimate files. Just like today. > > >>> Whitelisting will slow application development/deployment even more, >>> and will just result in more applications like Access and Excel that >>> provide a semi-IDE to the end user that allows them to develop their own >>> code/functionality. And resulting opportunities for code exploit. >> >> Bummer for them. Opportunity for those who can, and who can help them. > > Perhaps. Or maybe there's no ROI developing the feature in the first place. > > Or maybe exploits will just move to another area (Excel, Access application > etc) that whitelisting doesn't cover. > > You're not addressing the point at all. Whitelisting helps those who help themselves (corporately or individually). Think of it as evolution in action. After that, then yes, bad data is a problem. But bad data is the smaller problem. That *is* the point. To drive the point home - If I had to choose between whitelisting applications and blacklisting data, I'd choose whitelisting applications, every time. I'll still have some risk in my environment, but that's, to me, acceptable. Kurt ~ 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 ~ 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 ~ 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 ~ 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
