On Sat, Aug 08, 2009 at 08:33:45AM +0400, Cheney, Edward A SSG RES USAR USARC
wrote:
I do wish to be clear that when I say most significant I mean that
purely in a quantitative and not a qualitative manner. Vulernabilities
associated with client-side scripting are certainly not the most harmful
forms of security intrusion.
I'm not sure what you mean by "most significant in a quantitative manner",
if I might try to correctly put the pieces together. Do you mean (a) most
numerous in type, or (b) most numerous in scope, or (c) most numerous in
effect, or (d) something else? I'll certainly agree, for example, that
there are a lot of scripting exploits out there, and that they show up
on a lot of web sites, and that they seem to affect a lot of systems; but
I'm not sure which (if any) of those "lots" you're referring to.
As to whether they're most harmful or not, well, the best response I can
give to that is "it depends". Those that lead to full-system compromise
are certainly very harmful; those that only annoy the browser user much
less so.
But for the purpose of this discussion, it's probably not necessary
to get into these fine details. I'll grant that the scripting attacks
exists, and that there are enough of them that are sufficiently clever
to constitute a problem worth solving. My quarrel with the wording
is that it seemed awfully definitive about something that we're still
fumbling our way around: I don't think anybody's got statistics on these
that are any better than "educated guess". (More succinctly, we're
all wrong.)
These are (a) web browser and (b) operating system vulnerabilities,
and are quite readily mitigated by making sensible choices about both.
I draw a solid distinction between mitigation and solution. A
mitigation is a proactive action to ensure systems or data in your area
of responsibility are protected against security breaches from both
internal and external users. That is an attempt to avoid the problem,
and it is not a solution to the problem. A solution is a recommendation
that intends to eliminate the problem, which thereby reduces the scope
of mitigation in a given security assessment. In other words, if
actions to a system were really a solution to client-side security
vulnerabilities then those security flaws must never again occur upon
that system, correct?
For the sake of discussion, I'll accept this terminology, and amend my
comment to:
These are (a) web browser and (b) operating system vulnerabilities,
and are mostly solved by making sensible choices about both.
I say "mostly" because neither (a) nor (b) is a panacea. They remove
many of the vulnerabilities that client-side scripting tries to exploit,
but of course they don't remove them all. The other measures I suggested
(let's label them (c) browser extensions, e.g., NoScript and (d) filtering
or blocking HTTP proxies) would then, I suppose, still be mitigation,
not solutions, because they don't actual remove the vulnerability --
they just try to keep the attack from reaching it.
But whether we call them solutions or mitigation, the point is that all
of these exist today (in profusion), they can be used singly or in
combination for a defense-in-depth approach, and none of them require
us to do network engineering. And because of that last point, none of
them require web site, mail server, DNS, or other operators to make
significant efforts to accomodate them. (To put it another way, I could
compel all local users to migrate to Safari on MacOS X and push all
their HTTP requests through Privoxy; but if I did so, the scope of
that effort would be local-only, alleviating the need for the entire
rest of the 'net to accomodate my approach.)
My sense (and I won't claim that this is rigorous) of things is that
this general approach has barely been used. Enormous numbers of
people are still running Windows; most of them are still running IE.
Of the people who have migrated off Windows or IE, most of those are
not using extensions. And not many folks are running HTTP proxies
for their users' benefit. Yet doing all of these things, alone or
in combination, represents a lower level-of-effort with a higher
probability-of-success than starting a whole new engineering project.
More bluntly, if we can't get people to do the relatively simple,
relatively easy, relatively cheap things that we already know work
(for various values of "work") how will we possibly convince them to
do something much more complex, hard and expensive that may or may
not work?
If, on the other hand, poor choices of web browser and/or operating
system (or mail client, for that matter) are made, then it really
doesn't matter whether traffic moves via HTTP or SMTP or anything
else: those systems WILL be compromised.
Users can only be protected from themselves through adherance to
policies, procedures, and relevant training.
Well, on this we agree. But while this works (again, for some values
of "work") in some very limited and controlled settings, it doesn't
work at all at the scale of the Internet. Users will ignore policies,
forget procedures, and refuse training -- because they can. We can't
fix this with engineering because we can't fix this *at all*. What we
can do -- and we can do it today -- is furnish them with software
tools that make it less likely they'll inflict damage (and reduce
the scope of the damage that does happen), and we can do it without
major network/protocol engineering effort. We should really try these
simpler/available approaches before attempting anything more complicated.
---Rsk