Re: standards status in the industry - opinion?

[Nick FitzGerald <nick () virus-l demon co uk>]

Blue Boar to me:

> > So, you're saying that just because a bunch of morons designed 
> > something utterly brokenly (from a security perspective) from the 
> > outset _AND_ that much of the world "enjoys" the flexibility this 
> > approach has allowed (or is just too damned ill-informed or otherwise 
> > stupid to know any better), THAT informed security professionals (and 
> > others) should not try to get such gross stupidity fixed?
>
> I'm not saying that you shouldn't try, just that you probably won't 
> succeed.  In my experience, you "can't" take away some feature people like.

Oh I know that, but that doesn't stop me from hoping and trying...

> > And this is somewhat secondary anyway, for most/all script-based 
> > browser exploits _still_ have to drop some or other identifiably 
> > "executable" code (be it a binary or a file-based script or a file-
> > based macro or a file-based <whatever>) to do the bulk of the actual 
> > nastiness, and the whitelisting-based, integrity enforcement will 
> > _still_ stop the "payload" of the attack, even if their browser is 
> > vulnerable.
>
> I believe you can simply string together whitelisted programs to do what 
> you like.  Things like tftp.exe and format.exe.

You obviously have far too liberal a view of whitelisting.  You don't 
whitelist something just because you know (or are prepared to accept) 
that it is safe.  You whitelist _only_ those program files, DLLs, 
fonts, etc, etc that this user (or group of users) "needs" to do their 
legitimate work, that we have licenses for, etc, etc.  Remember, I am 
talking corporate use here -- you could even use a well-designed 
whitelisting system to prevent use of, say, MP3 files...

> > With known virus scanning you have to hope like hell that 
> > either your virus scanner has a good enough, generic enough (without 
> > raising silly FPs) detection of the browser exploit and will stop it 
> > (or at least alert you things have gone pear-shaped) as the bad 
> > HTML/script is written to the local browser cache OR that it already 
> > detects whatever it is that is dropped/further executes, etc (which 
> > increasingly, it doesn't).
>
> I wasn't even neccessarily talking about vulnerabilities per se.  I 
> don't consider enabling viruses to be a vulnerability, really.  Just a 
> side-effect of a general purpose OS.

I agree entirely (well, I'd the use word "function" rather than "side-
effect"...).

My point was that _if_ you use whitelisting you remove all access 
points apart from vulnerability exploits, so that is the only "point of 
weakness" left to beef-up and monitor for "unusual" activity.  That is 
_much_ better than the current "hope someone else caught it, realized 
they were infected, sussed-out what files were involved, got samples to 
their AV vendor (who sent samples to your AV vendor) who then analysed 
the program, addeded detection and shipped that in an update that your 
AV received _BEFORE_ another copy of the bad thing made it to your 
machines_.

(Of course, that such a process can still be deemed "acceptable" in 
large corporate LANs, almost across the board, raises a whole other, 
bigger set of questions about the competence of those that manage most 
of corporate IT.  A well-designed whitelisting approach should add no 
more than a few minutes per machine-class image generation (i.e. at the 
initial imaging stage, not per-machine that has that image installed on 
it).  It would remove 90+% of the "antivirus staff" requirement and add 
a very small additional cost to patch- and change-management (but far 
lower than the cost of the saved "antivirus management" staff).

> > Such a whitelisting approach then _mainly_ only leaves you vulnerable 
> > to arbitrary code execution through buffer overflows and the like and 
> > other forms of mitigation (reducing exposed services, developer 
> > education, improvements in compiler and runtime execution checks, 
> > DEP/NX/etc, and so on) are available to varying degrees for those.
>
> But to your point, whitelisting executables still leaves you vulnerable 
> to things like core worms, and you still have to have other security 
> measures to deal with those problems.

Yep, but current AV is pretty much hopeless against them too, so that 
is no impediment to replacing known virus scanning with "here is what 
is allowed" whitelisting.  The whitelisting approach reduces your 
uncertainty with respect to all file-based "unwanted code" to near 
enough to zero and certainly much closer to zero than the current AV 
approach (unless your IT staff are all as incompetent as the ones who 
currently choose to stick with "suck it and see" AV -- hmmmm, I may 
have just uncovered a flaw in this plan...  8-) ).


Regards,

Nick FitzGerald

_______________________________________________
Fun and Misc security discussion for OT posts.
https://linuxbox.org/cgi-bin/mailman/listinfo/funsec
Note: funsec is a public and open mailing list.