if i have a whitelist, do i still need AV?

Sandbox/Virtualization and Behavior Blockers are the future and the Signiture AV is going to die somewhere around the next 5-15 years.

 

Given that (a) there will always be a driver for some people to try to separate you from your identity/computing resources/cash and (b) there will always be downloadable content of unknown origin on the Internet, the view that any format of signature based product will disappear in the forseeable is naive at best. For that to happen, the content of the entire Internet would have to have been subject to prior "approval". Given the simple logisitics of managing an international resource, this is extremely unlikely to occur.

Blue

 

A combination of a limited account + software restriction policy as outlined, e.g., here is *very* close to a bulletproof whitelist.

Under a limited account at least the crucial parts of your OS are safe against tampering.

 

No, it won't die. It is a great tool to check modules for already known as bad.

 

Well, I agree that it wont die soon because it is still very useful. But if malware keeps developing like it is now then soon there will be more malware and undetected malware then AV companys can wright Signitures for.

And eventually we will hit a point where there will be so many malware samples in the database that it will slow computers running Signiture AV's down to almost unusable speeds.

On-Demand will see be an OK option thou since you do not have to run an On-Demand AV all the time and can use it wile you sleep or are not using the computer.

But with sandbox behavioral blocking and Virtulisation this will not be an issue because you do not need the computing power to calculate and scan the signitures.

 

they've been saying that (with variations on the time frame) for at least 10 years...

no, it isn't... i don't know how better to explain this other than to say that you have an overly narrow view of what a program is, which in turn leads to an overly optimistic view of the complexity of controlling them...

 

Can you point to an existing attack which will prove what you say?

--

 

that's a really good question... is it possible to demonstrate how far from bulletproof whitelisting really is with an example of an existing attack...

the fundamental problem is that for any sequence of bytes it is possible to construct an interpreter that will treat that sequence of bytes as code... in fact it's possible to create multiple interpreters that all treat the sequence of bytes as code and all produce different results when running that code so that that sequence of bytes can actually be multiple programs at the same time... can i prove that there is no limit to what can be treated as code using a single example? no, i very much doubt i can, but i can give examples: the jpeg virus from a few years back, ms office macros, perl scripts, kixstart scripts, batch files, obj infecting viruses, boot sectors, javascript, etc... no whitelist covers all program types, they'll only cover the mainstream program types because that's all they can afford to develop and that's all the user will accept (having to whitelist all data you want to use is beyond what anyone will accept), and that will only ever be the tip of the iceberg when it comes to the set of all program types...

 

Hi

How do whitelists really work? They block all files except for ones that have been specifically allowed right? If so, can it be evaded with new file types or something?

Thanks

 

no, they do not block all files... they block execution (whatever that may happen to be in the context in question) of known program types... they can be evaded with new or at least previously unrecognized program types...

 

What you have described sounds impressive, but until I have an attack to test, I don't know what weakness in the security needs bolstering.

By attack, I mean a website one visits where an attempt is made to infiltrate the computer.

--

 

i see... well then i guess you're out of luck, because i most definitely do not hand that sort of information out to people i don't know, let alone broadcast it in a public forum...

as for bolstering - there's really not a lot that can be done to make a whitelist less susceptible to this problem... if the object that maliciously takes advantage of this problem is known then it's fodder for known-malware scanning, otherwise you better hope that either your behaviour blocker stops the interpreter or that the interpreter is a program you generally run sandboxed...

 

Hi

Thanks. Does this happen often?

 

as a malicious attack? doubtful... whitelists haven't gained enough marketshare to make it worth the effort yet..

as a benign consequence of application flexibility and rich documents, however, it probably happens all the time without anyone giving it a second thought...

 

Don't forget AV's have heuristics now too.

I don't use an AV. Sandboxie & CFP D+ (HIPS) Does the job for me.

 

Whitelists Killed AV?

 

It sounds as though whitelisting then really isn't 'default deny', as only known program types are denied by default.

How, for example, can a HIPS be bypassed with an unknown program type?

 

Can you explain what you mean by an "unknown program type"?

---

 

"...new or at least previously unrecognized program types..." from post #35.

 

Thanks, Dogbiscuit, that's from a week ago and I lost track!

Actually, nothing useful since #36 and #37 because no current attacks have been listed so as to test against "unrecognized program types."

---

 

it's default deny with limitations (everything has limitations)...

that depends a lot on what exactly you mean by HIPS... it's a term that's thrown around a lot but doesn't actually describe one particular technology...

it also depends on the particulars of the program type... assuming you're referring to some sort of behaviour-based technology, back when macro viruses were still not really well known one might have allowed word to interact with outlook to send emails, for example, because you regularly send documents after you're finished with them... macro viruses would then have been able to bypass a behaviour-based preventative control because the interpreting process would have been given sufficient rights for the macro virus to do it's dirty deed...

 

try thinking like an attacker... you've got a security technology that blocks the execution of a fixed number of program types, just look for any type of program outside that list... if you know a data file format includes sections that are interpreted as instructions, authorize the interpreter and then see if the technology blocks the interpretation of the data file...

there are all sorts of things you could try... you could try the perl interpreter, for example... you could install cygwin and try a bash script... have you checked whether or not simple batch files are blocked?

and here's another angle - if you have a whitelist operating on the host system, will it block programs in a virtual machine running on that guest system? your host system should, of course, be protected from what's running in a virtual machine but if the VM has network access then what about the other devices on your network (like your router)... for that matter, will your whitelist stop java or javascript or flash or silverlight or any number of other active web content technologies that could send http requests to your router and change it's dns settings...

while i won't point people at actual attacks, it should only require a little bit of creativity to find at least one thing that your whitelist won't stop (without any attack being involved)...

 

Execution control software (e.g., something like ProcessGuard) for these purposes.

 

Doesn't that usually require some type of vulnerability in the interpreter that is exploited, since most software is designed to prevent exploitation? (e.g., javascript) Or am I missing something?

 

yes, you're missing something... you're missing the fact that what the interpreter is interpreting are programs by design (no vulnerabilities required)... if the whitelist/execution control system isn't requiring each of those programs to be authorized before being interpreted then you've found a way to bypass the whitelist... what those programs can do certainly depends on what the interpreted language allows but there are plenty that give filesystem access, and that's assuming a piece of malware even needs filesystem access (plenty can operate right in the context of your browser without ever trying to read or write files - javascript is plenty flexible enough for driveby pharming or keylogging)...