Below you can see that Apache 2.0 (RH 8) does echo back all the headers that you send to it with your TRACE command.
And rereading the RFC, I gather that is just what it should be doing. According to the whitepaper then.... The exploit then is one that allows a client side script to read information (cookies for now) that are already in the client but that are supposed to be hidden from the script. The script uses some technology within the browser to generate its own HTTP request. The browser goes along with the game and fills in the cookie information that should be hidden. The script sends the request and gets to read the response. Since the request is a TRACE, the response includes the hidden cookie information. It goes away entirely if the server doesn't implement TRACE. It will not cause cross site leakage unless your browser already has a cross site leakage bug in it. IE currently does. Other browsers may or may not have bugs. When will you be secure that your browser has none of these bugs? If your browser has a cross site scripting bug, if you visit multiple websites with trace on, you can have a cross site scripting exploit. So the short term fix for YOU the webuser is to have your proxy remove all TRACE requests. Let's give that one an unlikely tag. The news article claims that Apache needs a patch and can't just be configured to not implement TRACE. Does anyone know if that is so? Jerry KRUSTY$ telnet homer.theashergroup.com 16040 Trying 192.168.0.32... Connected to homer.theashergroup.com. Escape character is '^]'. TRACE / HTTP/1.1 HOST: homer.theashergroup.com COOKIE: foo=bar HTTP/1.1 200 OK Date: Wed, 22 Jan 2003 22:35:26 GMT Server: Apache/2.0.40 (Red Hat Linux) Content-Length: 68 Content-Type: message/http TRACE / HTTP/1.1 HOST: homer.theashergroup.com COOKIE: foo=bar Connection closed by foreign host. KRUSTY$
