[Full-Disclosure] Re: New Web Vulnerability - Cross-Site Tracing

From: Steven M. Christey (coleyat_private)
Date: Thu Jan 23 2003 - 18:41:32 PST

  • Next message: Glynn Clements: "Re: Can System() of Perl be bypassed?"

    >> = me
    > = xss-is-lame@hushmail
    
    
    >> 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
    _______________________________________________
    Full-Disclosure - We believe in it.
    Charter: http://lists.netsys.com/full-disclosure-charter.html
    



    This archive was generated by hypermail 2b30 : Thu Jan 23 2003 - 19:24:57 PST