Message-ID: <1043281513.6476.563.camel@localhost.localdomain>
From: jeremiah at whitehatsec.com (Jeremiah Grossman)
Subject: Re: New Web Vulnerability - Cross-Site Tracing

On Wed, 2003-01-22 at 15:52, xss-is-lame@...hmail.com wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----


> My objection is to the way that the whole issue was framed and presented.  I realize that 
everyone has to gloss things up a bit for marketting and dumb things down for laypeople, but 
I think that the press release, the whitepaper and particularly the ExtremeTech article all 
overstep what is excusable.  They are sensational and exagerated.

We do not believe PR statement or white paper misrepresented anything.
If fact we got the help from many known experts to make sure we did the
best job we could and everything was as clear as we could make it. We
also dont control media coverage.


> Some examples for the whitepaper and press release:
> "First of all, anything that attempts to help prevent the xss plague on the web is a good thing."
> 
> The XSS plague?  The only XSS plague I know of is on Bugtraq and other disclosure 
mailing lists.  Is anyone else sick of seeing posts about XSS problems in PHP applications 
that runs on a total of five sites?  

We are sick of seeing it as well. And XSS is in everything and near
impossible to get rid of. Aka. plague.


Code Red was a plague.  Melissa was a plague.  In all 
the time XSS has been around, I only know of a few instances where it has actually been used.  
Do you have any evidence of an actual XSS epidemic taking place?


Well being a security expert in the field I can hardly comment on
specifics but yes... it does happen. Often? Whats Often?


> 
> "What sites currently have TRACE enabled?"
> 
> The obvious implication here is that an attacker could somehow compromise these sites. 
There really isn't a point in listing some big name sites that are vulnerable to this after 
you've stated that nearly everywhere has TRACE enabled.  This also makes it look like the
problem is focused on the server, when the more serious issue is obviously the ability to
 use ActiveX objects to create raw HTTP requests.


We feel the problem is located at the server, but the client-side still
has issues as well. We cover those in the paper. We mentioned site
examples of who supports trace simply to identify who supports what. If
would be pointless if we used a request method no one supports, wouldnt
it?


> This is a laughable, sensationalist statement.  

we dont feel it to be laughable... but..frightening.



There is *long* list of issues that have 
been reported since then that are many times more serious than this.  Chunked encoding issues, 
the OpenSSL overflow, the CVS problem, etc. etc. etc.  A year from now, how many credential 
sets do you think will actually have been compromised using this technique?  Do you honestly 
think it's up in the Code Red and Nimda range?

We hope it doesnt get to that point surely. But you could take it up
with who made the quote I guess.

 
> This is creates a false implication: If you turn off TRACE, the security of the domain 
credentials no longer resides in the security of the web browser.  This is not true.  The 
web browser can still give out credentials if attacked with normal XSS, ActiveX exploits, 
etc.  

Indeed. but not using this method.


The web browser must be trusted to protect the credentials it uses, no matter what.


to an extent. the smallest extent possible Im sure you'd agree.


> I hope that this clarifies my dissapointment with this issue.  It's a nice hack, don't 
get me wrong, but it's much less serious than many other issues that get reported with 
less hoopla and fluff.
> 
> Feedback (negative or positive) is welcome.

Crystal clear. thank you.


Any comments on the actual exploit in which potential attack vectors
might be present?

Powered by blists - more mailing lists