From: coley at linus.mitre.org (Steven M. Christey)
Subject: Re: New Web Vulnerability - Cross-Site Tracing

>> = me
> = xss-is-lame@...hmail


>> XSS (including "HTML injection" for those who make such distinctions)
>> was the 2nd most frequently reported vulnerability last year, behind
>> buffer overflows, based on CVE statistics.

>This is a pretty meaningless statistic unless you can link it, through
>association by cause, to actual exploitation.  The fact that you
>acknowledge that XSS is not being widely exploited pretty much proves
>this worthless.

I think it's an important stat because *if* XSS becomes widely
exploited, then it could pose a significant threat.

>>it seems likely that applications will become a more attractive target
>>to hackers as it gets more difficult to break into servers.
>
>"It seems likely", eh?  So in other words, there is no widespread
>abuse of XSS problems.

Agreed.

>The word "plague" has an extremely strong negative conontation.
>Consider a biblical analogy.

I think we're looking at this from two different sides: I see a plague
in the sense that a large number of applications have these bugs in
the first place.  You say it can't be a plague until those bugs are
being actively exploited.  And of course you have a point, but I think
it would be best to fix these issues before finding out how serious
they can be.  That practice seems to have worked well in the past
("non-exploitable" heap-based buffer overflows come to mind).  In
addition, strategically speaking, I think XSS is a good "learning
tool" for educating programmers about trusting input, and the
involvement of three parties in XSS (attacker, victim, and server)
introduces an additional layer of complexity that is useful in
demonstrating that attack scenarios do not necessarily need to be
perfectly straightforward.

>I would also like evidence supporting your claim that servers are
>becoming more difficult to break into.

I don't have statistics.  Here's what I meant to say: "servers from
major vendors/developers are less likely to be prone to the same-old,
same-old obvious vulnerabilities like classic buffer overflows and
directory traversal."  (Here, I use "classic overflows" to distinguish
from things like array index modification, length field tampering, and
integer signedness errors that happen to use overflow-style attacks
but stem from something other than "really long string.")

By "servers," I mean "software implementations of networking
protocols," not physical machines.  So maybe we are using different
definitions here.

>For the last few years, the trend is the opposite.  The widespread
>adoption of web technologies has *dramatically* lowered the bar in
>terms of difficulty.

I agree, partially because they allow non-programmers or non-experts
to add functionality.  But these technologies generally enable the
development and deployment of web *applications*, not entirely new
servers on a par with Apache.  I apologize for not making this
distinction more clearly.

>On the other hand, SQL injection is easy.

Yes, but it generally occurs in applications, not the servers that run
the applications.

>let's look at buffer overflows, which I'm sure you'll admit are
>nowhere near in the ballpark of being adequately protected against by
>most programmers.  So let's say everyone picks up .NET or Java.  No
>more buffer overflows.  (We'll leave "virtual machine overflow"
>theories out of this discussion.)  There will be new attack paradigms.
>SQL injection is "new".  XXE is "new".  Next week there may be
>something else "new".  There will be plenty of new ways to attack
>systems that anyone who wants to can find out about.

Agreed, this is a moving target.  But at some point in time, maybe we
will run out of new ways of manipulating simple inputs in a
security-critical fashion, which would leave us with more complex bugs
(that would hopefully be more difficult to exploit), and maybe
advances in OSes and compilers will help reduce the overall threat
even if something new is discovered.

>I'm sure there are arguments to be made for programmers getting better
>in terms of security.  There are now secure programming books, guides,
>mailing lists, etc. so that those who want to learn how to code in a
>secure fashion can do so.  These make programmers be *able* to get
>better at programming securely, but it doesn't inherently make it so.

Agreed, until customers ask for it, and security begins to affect the
vendors' bottom line.  I believe that's starting to happen, but others
probably disagree.

>> Personally, I'm glad to see the contributions made by up-and-coming
>> vulnerability auditors who get their start by auditing easier targets.
>
>This actually made me laugh.

I recognize that this opinion is probably unusual.  And as you say,
there can be many different motivations for finding bugs.  Not
everyone can do PhD level vulnerability research, but we don't need
everyone to be a PhD either.

>I'm no psychologist, but I think that the people that find these XSS
>bugs are essentially script kiddies (even if they're "whitehats",
>there are plenty of "whitehat" script kiddies out there) who are
>trying to convince themselves that they're real hackers.

Regardless of their motivations, they still perform a valuable
function by identifying and defeating software that is so insecure
that simple attacks are successful.

>In a perfect world... BugTraq would only contain posts from qualified
>people with real issues to share.

With the increasing number of vulnerabilities, I'm surprised that we
haven't seen a new mailing list with this specific mission.

>Finding XSS bugs is trivial.  Much harder than, say, developing an
>exploit for a chunked encoding issue.  So like most people in this
>world, they take the path of least resistance

... and the path of least resistance will not work on software that
has been locked down well in the first place.  Again I don't have hard
statistics, but over the last year or two, it seems that most of the
serious bugs in major software were found by top notch researchers,
not Jane Doe.

>Theory is theory until proven otherwise.  XSS is not appealing to
>hackers when there are so many other more direct and interesting ways
>of compromising systems.  As I've explained, I don't think that is
>likely to change in the near future.

It doesn't seem likely to me either, but wouldn't it be nice if we
prevented such attacks before they happen?

>The bottom line with this whole XSS thing is that it's been blown WAY
>out of proportion by both security companies and "vulnerability
>researchers".  XSS has been portrayed as something that is definitely
>being widely exploited (it's not, if you disagree, I want proof),

I don't think we've seen any proof of widespread exploitation.  But
that should only affect how XSS is prioritized as a vulnerability
class, not whether it should be eliminated or not.

>something that is very dangerous and can directly lead to a server
>compromise (in most cases, all you can do is impersonate authorized
>users),

... which, in the case of e-business, is equivalent to a server
compromise if it allows theft; or, in other cases, equivalent to
violations of privacy.  At the end of the day, the server does not
matter, rather its users.

>Please read what I've written here and consider it seriously.
>Hopefully it will change your mind about some things.

It has helped to clarify some of my own thinking.

I'm not saying that XSS is as much of a threat as buffer overflows.
And maybe it won't ever be widely exploited, for whatever technical or
social reasons that may come along.  However, its prevalence is a
reflection of some widespread, fundamental gaps in secure programming
and testing.  And I don't think that the vulnerability research
community really fully understand XSS as a class.  Look at the varying
analyses that have come out regarding the XST issue.

>Whether or not your predictions occur *will* reflect on your
>professional reputation.  (Yes, I'm aware that I'm cheating by hiding
>behind a Hushmail account, but you'll probably find out who I am
>sometime before we know how this XSS thing turns out.)

Hopefully enough people will concentrate on your technical arguments
rather than what email address you happen to be using.


- Steve

Powered by blists - more mailing lists