Re: [AOLSERVER] Is Aolserver vulnerable?
On 2003.01.22, Jade Rubick <[EMAIL PROTECTED]> wrote: > Does Aolserver implement the TRACE command? > > http://www.extremetech.com/article2/0,3973,841047,00.asp $ telnet www.panoptic.com 80 Trying 216.25.146.66... Connected to www.panoptic.com. Escape character is '^]'. TRACE / HTTP/1.1 Host: www.panoptic.com:80 HTTP/1.0 404 Not Found MIME-Version: 1.0 Date: Wed, 22 Jan 2003 21:27:30 GMT Server: AOLserver/3.5.0 Content-Type: text/html Content-Length: 548 Connection: close Not by default. You could always register a filter that handled TRACE requests. I might just do that to see what kind of exploits are being used out there ... log any TRACE attempts. ;-) Thanks for mentioning this. -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70)
Re: [AOLSERVER] Is Aolserver vulnerable?
In a message dated 1/22/2003 4:29:34 PM Eastern Standard Time, [EMAIL PROTECTED] writes: Not by default. You could always register a filter that handled TRACE requests. I might just do that to see what kind of exploits are being used out there ... log any TRACE attempts. ;-) I believe TRACE is an HTTP/1.1 option, which would mean AOLserver is NOT vulnerable since we're still only HTTP/1.0 compliant. - Nathan
Re: [AOLSERVER] Is Aolserver vulnerable?
After looking through the 3.4.2 source code, the answer is no. TRACE is not a supported HTTP method in AOLserver. I used cscope to find all occurences of TRACE and found none. Also checked the Tcl module that come with the server. It might be wise to register a proc to log that a TRACE request was made to your server, if you're interested to identify attempts. /s. On Wednesday, January 22, 2003, at 03:04 PM, Jade Rubick wrote: Does Aolserver implement the TRACE command? http://www.extremetech.com/article2/0,3973,841047,00.asp
Re: [AOLSERVER] Is Aolserver vulnerable?
Incidentally, Apache/1.3.26, the version shipped with Debian 3.0, DOES implement TRACE. On Wed, Jan 22, 2003 at 01:04:36PM -0800, Jade Rubick wrote: > Does Aolserver implement the TRACE command? > > http://www.extremetech.com/article2/0,3973,841047,00.asp On Wed, Jan 22, 2003 at 04:29:26PM -0500, Dossy wrote: > On 2003.01.22, Jade Rubick <[EMAIL PROTECTED]> wrote: > > Does Aolserver implement the TRACE command? > > > > http://www.extremetech.com/article2/0,3973,841047,00.asp > > $ telnet www.panoptic.com 80 > Trying 216.25.146.66... > Connected to www.panoptic.com. > Escape character is '^]'. > TRACE / HTTP/1.1 > Host: www.panoptic.com:80 > > HTTP/1.0 404 Not Found > MIME-Version: 1.0 > Date: Wed, 22 Jan 2003 21:27:30 GMT > Server: AOLserver/3.5.0 > Content-Type: text/html > Content-Length: 548 > Connection: close -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com
Re: [AOLSERVER] Is Aolserver vulnerable?
On Wednesday, January 22, 2003, at 03:48 PM, Andrew Piskorski wrote: Incidentally, Apache/1.3.26, the version shipped with Debian 3.0, DOES implement TRACE. On Wed, Jan 22, 2003 at 01:04:36PM -0800, Jade Rubick wrote: Does Aolserver implement the TRACE command? http://www.extremetech.com/article2/0,3973,841047,00.asp I just pointed that out to my management chain and the other groups in my organization who use Apache and IIS. Here's the message I sent: = CUT HERE If you aren't already aware, there appears to be a serious cross-site vulnerability that uses the TRACE HTTP method to do its dirty work. This vulnerability is not affected by SSL. Please read: http://www.extremetech.com/article2/0,3973,841047,00.asp I know Apache uses the TRACE method (I just looked at the source code for Apache), but it may not be vulnerable depending on how Apache is configured. I can't determine if IIS is vulnerable, because, well, I don't have the source code. We use AOLserver for EMIS, which is not vulnerable. I've added extra checking to the EMIS request processor 5 minutes ago to log any attempts to use HTTP methods that we don't accept so we can identify attempts to use TRACE. Here's the piece of code I added to do that: if {! [regexp -nocase {get|post|head} $http_method]} { ns_log warning "BAD HTTP METHOD: $http_method from $peer_addr: HTTP REQ=$request" ns_return 403 text/html [ns_adp_parse -file /emis/pages/errors/errorframe.adp 403] return filter_return } else { ns_log notice "$http_method request for $request from $peer_addr" } AOLserver is such a *sweet* web server. You should really consider switching :) /s. === CUT HERE == So, thank you AOL, the AOL dev team, and everyone in the community who uses and has helped maintain and improve AOLserver. You've made my life so much easier. /s.
Re: [AOLSERVER] Is Aolserver vulnerable?
Jade Rubick wrote: Does Aolserver implement the TRACE command? http://www.extremetech.com/article2/0,3973,841047,00.asp Here's what RFC 2616 says about TRACE. This is just about all it says about TRACE. The other mentions are about issues that couldn't cause an exploit: http://www.ietf.org/rfc/rfc2616.txt 9.8 TRACE The TRACE method is used to invoke a remote, application-layer loop- back of the request message. The final recipient of the request SHOULD reflect the message received back to the client as the entity-body of a 200 (OK) response. The final recipient is either the origin server or the first proxy or gateway to receive a Max-Forwards value of zero (0) in the request (see section 14.31). A TRACE request MUST NOT include an entity. TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing or diagnostic information. The value of the Via header field (section 14.45) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an infinite loop. If the request is valid, the response SHOULD contain the entire request message in the entity-body, with a Content-Type of "message/http". Responses to this method MUST NOT be cached. I am printing out WhiteHat's WhitePaper now (on my own highly patented WritePaper (TM)): http://www.cgisecurity.com/whitehat-mirror/WH-WhitePaper_XST_ebook.pdf. But this is exploit is evidently related to cross site scripting. Anyway, my own initial thoughts are that I am thinking the problem is not reflecting back the messages, but including all the cookies and headers in the message. If so, there is nothing in the RFC that I can see that suggests an HTTP 1.1 server needs to send anything other than a 200 header. The VIA header IS an information leak, but if I recall from the past, lots of actual proxies don't implement that header anyway And it would be a reasonable thing to do to NOT implement it. If the problem is sending anything at all and not just the headers, well I confess thinking: Wow. Cool. Bad. Jerry
Re: [AOLSERVER] Is Aolserver vulnerable?
On Wed, Jan 22, 2003 at 04:07:18PM -0600, Scott Goodwin wrote: > > AOLserver is such a *sweet* web server. You should really consider > switching :) :-D > So, thank you AOL, the AOL dev team, and everyone in the community who > uses and has helped maintain and improve AOLserver. You've made my life > so much easier. Speaking of that, is 4.0 going to support at least part of HTTP 1.1? -Roberto -- +|Roberto Mello -http://www.brasileiro.net/ |--+ + Computer Science Graduate Student, Utah State University + + USU Free Software & GNU/Linux Club - http://fslc.usu.edu/ + For sale: Hourglass for timing Windows.
Re: [AOLSERVER] Is Aolserver vulnerable?
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$
Re: [AOLSERVER] Is Aolserver vulnerable?
Scott Goodwin wrote: have the source code. We use AOLserver for EMIS, which is not vulnerable. I've added extra checking to the EMIS request processor 5 minutes ago to log any attempts to use HTTP methods that we don't accept so we can identify attempts to use TRACE. Here's the piece of code I added to do that: if {! [regexp -nocase {get|post|head} $http_method]} { ns_log warning "BAD HTTP METHOD: $http_method from $peer_addr: HTTP REQ=$request" ns_return 403 text/html [ns_adp_parse -file /emis/pages/errors/errorframe.adp 403] return filter_return } else { ns_log notice "$http_method request for $request from $peer_addr" } This is a good idea. You may wish to change this to return a TRACE specific error message that mentions this exploit. That way the user will be alerted to dubious activity on his machine. Jerry
Re: [AOLSERVER] Is Aolserver vulnerable?
How do you register this filter? I have a list of methods I check for but I would prefer to watch for all that are not get/post/head On Wednesday 22 January 2003 04:53 pm, Jerry Asher wrote: > Scott Goodwin wrote: > > have the source code. > > > > We use AOLserver for EMIS, which is not vulnerable. I've added extra > > checking to the EMIS request processor 5 minutes ago to log any attempts > > to use HTTP methods that we don't accept so we can identify attempts to > > use TRACE. Here's the piece of code I added to do that: > > > > if {! [regexp -nocase {get|post|head} $http_method]} { > >ns_log warning "BAD HTTP METHOD: $http_method from $peer_addr: HTTP > > REQ=$request" > >ns_return 403 text/html [ns_adp_parse -file > > /emis/pages/errors/errorframe.adp 403] > >return filter_return > > } else { > >ns_log notice "$http_method request for $request from $peer_addr" > > } > > This is a good idea. > > You may wish to change this to return a TRACE specific error message > that mentions this exploit. That way the user will be alerted to > dubious activity on his machine. > > Jerry
Re: [AOLSERVER] Is Aolserver vulnerable?
On Wed, Jan 22, 2003 at 02:47:58PM -0800, Jerry Asher wrote: > 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? Ugh. > 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? Think I found a way to work around the problem using Apache's mod_rewrite (something that may be good to add to OpenACS' request processor). By adding the lines below (with mod_rewrite being loaded) to the VirtualHost section, the server should send a Forbidden response. Weirdly, I get a Bad request (the same request works fine if I take the rewrite rules off), but at least the TRACE isn't completed. # RBM: 2002-01-22. Kill TRACE exploits. RewriteEngine on RewriteCond %{REQUEST_METHOD} ^TRACE RewriteRule .* [F] -Roberto -- +|Roberto Mello -http://www.brasileiro.net/ |--+ + Computer Science Graduate Student, Utah State University + + USU Free Software & GNU/Linux Club - http://fslc.usu.edu/ + What you end up with, after running an operating system concept through these many marketing coffee filters, is something not unlike plain hot water. -- Matt Welsh
Re: [AOLSERVER] Is Aolserver vulnerable?
Thanks for the specific info on the vulnerability -- your summary seems so much clearer to me. The code below does log the method attempted -- from there we have an automated script that identifies wierd stuff for analysis. thanks, /s. On Wednesday, January 22, 2003, at 04:53 PM, Jerry Asher wrote: Scott Goodwin wrote: have the source code. We use AOLserver for EMIS, which is not vulnerable. I've added extra checking to the EMIS request processor 5 minutes ago to log any attempts to use HTTP methods that we don't accept so we can identify attempts to use TRACE. Here's the piece of code I added to do that: if {! [regexp -nocase {get|post|head} $http_method]} { ns_log warning "BAD HTTP METHOD: $http_method from $peer_addr: HTTP REQ=$request" ns_return 403 text/html [ns_adp_parse -file /emis/pages/errors/errorframe.adp 403] return filter_return } else { ns_log notice "$http_method request for $request from $peer_addr" } This is a good idea. You may wish to change this to return a TRACE specific error message that mentions this exploit. That way the user will be alerted to dubious activity on his machine. Jerry
Re: [AOLSERVER] Is Aolserver vulnerable?
I actually don't have to perform the 'if' check regexp -- we register two handlers, one for accepted method, the other for unacceptable methods: ns_register_filter preauth GET /* rp_handler ns_register_filter preauth POST /* rp_handler ns_register_filter preauth PUT /* rp_handler_other ns_register_filter preauth HEAD /* rp_handler_other ns_register_filter preauth DELETE /* rp_handler_other ns_register_filter preauth TRACE /* rp_handler_other ns_register_filter preauth OPTIONS /* rp_handler_other ns_register_filter preauth CONNECT /* rp_handler_other rp_handler_other handles "bad" methods. So I can go in and simplify the code :) /s. On Wednesday, January 22, 2003, at 05:08 PM, David Walker wrote: How do you register this filter? I have a list of methods I check for but I would prefer to watch for all that are not get/post/head On Wednesday 22 January 2003 04:53 pm, Jerry Asher wrote: Scott Goodwin wrote: have the source code. We use AOLserver for EMIS, which is not vulnerable. I've added extra checking to the EMIS request processor 5 minutes ago to log any attempts to use HTTP methods that we don't accept so we can identify attempts to use TRACE. Here's the piece of code I added to do that: if {! [regexp -nocase {get|post|head} $http_method]} { ns_log warning "BAD HTTP METHOD: $http_method from $peer_addr: HTTP REQ=$request" ns_return 403 text/html [ns_adp_parse -file /emis/pages/errors/errorframe.adp 403] return filter_return } else { ns_log notice "$http_method request for $request from $peer_addr" } This is a good idea. You may wish to change this to return a TRACE specific error message that mentions this exploit. That way the user will be alerted to dubious activity on his machine. Jerry
Re: [AOLSERVER] Is Aolserver vulnerable?
I think a registered filter put in before any other filter would be better, unless you have a specific error page you want to show that's in OpenACS. My code is returning our error page; I wouldn't want to rely on a more complex module to perform this function for me. A bug in your rewrite code could make you vulnerable again. /s. On Wednesday, January 22, 2003, at 05:19 PM, Roberto Mello wrote: On Wed, Jan 22, 2003 at 02:47:58PM -0800, Jerry Asher wrote: 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? Ugh. 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? Think I found a way to work around the problem using Apache's mod_rewrite (something that may be good to add to OpenACS' request processor). By adding the lines below (with mod_rewrite being loaded) to the VirtualHost section, the server should send a Forbidden response. Weirdly, I get a Bad request (the same request works fine if I take the rewrite rules off), but at least the TRACE isn't completed. # RBM: 2002-01-22. Kill TRACE exploits. RewriteEngine on RewriteCond %{REQUEST_METHOD} ^TRACE RewriteRule .* [F] -Roberto -- +|Roberto Mello -http://www.brasileiro.net/ |--+ + Computer Science Graduate Student, Utah State University + + USU Free Software & GNU/Linux Club - http://fslc.usu.edu/ + What you end up with, after running an operating system concept through these many marketing coffee filters, is something not unlike plain hot water. -- Matt Welsh
Re: [AOLSERVER] Is Aolserver vulnerable?
On Wed, Jan 22, 2003 at 04:19:05PM -0700, Roberto Mello wrote: > RewriteEngine on > RewriteCond %{REQUEST_METHOD} ^TRACE > RewriteRule .* [F] That almost works, but the RewriteRule is missing the substitution string (even though that string seems to be ignored in this case): RewriteRule .* - [F] That code needs to be repeated for each Apache VirtualHost, or inherited with this (also in each VirtualHost): RewriteEngine on RewriteOptions inherit -- Fred Yankowski [EMAIL PROTECTED] tel: +1.630.879.1312 OntoSys, IncPGP keyID: 7B449345fax: +1.630.879.1370 www.ontosys.com 38W242 Deerpath Rd, Batavia, IL 60510-9461, USA
Re: [AOLSERVER] Is Aolserver vulnerable?
On Wed, Jan 22, 2003 at 04:19:05PM -0700, Roberto Mello wrote: > > Think I found a way to work around the problem using Apache's mod_rewrite > (something that may be good to add to OpenACS' request processor). By > adding the lines below (with mod_rewrite being loaded) to the VirtualHost > section, the server should send a Forbidden response. I forgot to give due credit... This fix was concocted by Doran Barton, a friend of mine, in a discussion in #linux of our LUG IRC server (fslc.usu.edu). He happens to be an apache/perl guy. -Roberto -- +|Roberto Mello -http://www.brasileiro.net/ |--+ + Computer Science Graduate Student, Utah State University + + USU Free Software & GNU/Linux Club - http://fslc.usu.edu/ + 5¼" hard is better than 3½" floppy.
Re: [AOLSERVER] Is Aolserver vulnerable?
On Wed, Jan 22, 2003 at 07:33:25PM -0600, Fred Yankowski wrote: > On Wed, Jan 22, 2003 at 04:19:05PM -0700, Roberto Mello wrote: > > RewriteEngine on > > RewriteCond %{REQUEST_METHOD} ^TRACE > > RewriteRule .* [F] > > That almost works, but the RewriteRule is missing the substitution > string (even though that string seems to be ignored in this case): > > RewriteRule .* - [F] > > That code needs to be repeated for each Apache VirtualHost, or > inherited with this (also in each VirtualHost): > > RewriteEngine on > RewriteOptions inherit Great! Thanks for the fix and clarification. -Roberto -- +|Roberto Mello -http://www.brasileiro.net/ |--+ + Computer Science Graduate Student, Utah State University + + USU Free Software & GNU/Linux Club - http://fslc.usu.edu/ + I'm a programmer, I don't do COBOL.
Re: [AOLSERVER] Is Aolserver vulnerable?
Before rushing to patch all your servers so that they never respond to TRACE requests make sure you read this posting by Marc Slemko on the topic: http://marc.theaimsgroup.com/?l=bugtraq&m=104328339022104&w=2 -- Branimir
Re: [AOLSERVER] Is Aolserver vulnerable?
In a message dated 1/22/2003 5:38:18 PM Eastern Standard Time, [EMAIL PROTECTED] writes: Speaking of that, is 4.0 going to support at least part of HTTP 1.1? -Roberto What portions do you think would make the most sense to support, and what benefits would supporting those features provide? I'd recommend thinking about these things in terms of a model where all static content (images, _javascript_, css, etc.) is served from a separate process leaving the AOLserver free to serve dynamic .adp pages. - Nathan
Re: [AOLSERVER] Is Aolserver vulnerable?
+-- On Jan 23, Nathan Folkman said: > What portions do you think would make the most sense to support, and what > benefits would supporting those features provide? Keep-alive enabled by default - allows persistent client/server connections without negotiation. Chunked transfer coding - allows streaming content within persistent connections. Byte ranges - allows a client to resume an interrupted transfer.
Re: [AOLSERVER] Is Aolserver vulnerable?
-Original Message-From: AOLserver Discussion [mailto:[EMAIL PROTECTED]]On Behalf Of Nathan FolkmanSent: 23 January 2003 22:57To: [EMAIL PROTECTED]Subject: Re: [AOLSERVER] Is Aolserver vulnerable?In a message dated 1/22/2003 5:38:18 PM Eastern Standard Time, [EMAIL PROTECTED] writes: Speaking of that, is 4.0 going to support at least part of HTTP 1.1?-Roberto What portions do you think would make the most sense to support, and what benefits would supporting those features provide? I'd recommend thinking about these things in terms of a model where all static content (images, _javascript_, css, etc.) is served from a separate process leaving the AOLserver free to serve dynamic .adp pages.- Nathan [Moss, Tim] Even in that situation (with which I completely agree by the way; it enables you to tune those servers for the specific purpose and achieve phenomenal performance - e.g. regularly rsync all the static content onto a memory based file system, from which the server reads. Or give the server huge amounts of RAM in which to cache all the static content, or both perhaps) ... even in that situation the HTTP/1.1 Keep-Alive features are of great benefit both to the client and the server: the client only suffers from any network latency twice (once for the HTML and once for all static objects in the page) - On a high latency connection this can be significant in terms of page download speed. the server has to deal with fewer (on average at least a factor of 10) incoming connections which whilst not particularly costly on an individual basis, they all add up, Other than the Keep-Alives, I don't think any of the other features HTTP/1.1 offers above 1.0 are anywhere near as significant in practice, but it would be nice to be able to support them I suppose. The fact that a Host header is required simplifies some things, and some of the Cache-Control and ETag headers are nice ideas, but in practice there's no guarantee that the clients, (or indeed the proxies, caches etc between the client and the server) respond to them in a sensible way, if at all.
Re: [AOLSERVER] Is Aolserver vulnerable?
In a message dated 1/23/2003 6:24:22 PM Eastern Standard Time, [EMAIL PROTECTED] writes: >What portions do you think would make the most sense to support, and what >benefits would supporting those features provide? Keep-alive enabled by default - allows persistent client/server connections without negotiation. Chunked transfer coding - allows streaming content within persistent connections. Byte ranges - allows a client to resume an interrupted transfer. Are byte ranges useful outside big static file downloads? -Jim
Re: [AOLSERVER] Is Aolserver vulnerable?
+-- On Jan 23, Jim Davidson said: > Are byte ranges useful outside big static file downloads? I don't know. One level of possibly useful support would be simply to have AOLserver parse the byte-range request and make it available via an API. For example, a site that stores large binary objects in a database could use the API to return a byte range. Another level of support would be to make fastpath and ns_returnfile use the byte-range info to return just the requested portion of a file. API. A site that delivers large binary files from a database might find this useful. I implemented this in 3.3+ad12. At ArsDigita we only used AOLserver - we didn't have a separate server for static files.
Re: [AOLSERVER] Is Aolserver vulnerable?
Adobe's Acrobat Viewer supports byte range serving when installed as a plug-in for Netscape Navigator, or as an ActiveX control for Microsoft's Internet Explorer. It'll pull down a page at a time as you move through the document. /s. On Thursday, January 23, 2003, at 06:47 PM, Jim Davidson wrote: In a message dated 1/23/2003 6:24:22 PM Eastern Standard Time, [EMAIL PROTECTED] writes: >What portions do you think would make the most sense to support, and what >benefits would supporting those features provide? Keep-alive enabled by default - allows persistent client/server connections without negotiation. Chunked transfer coding - allows streaming content within persistent connections. Byte ranges - allows a client to resume an interrupted transfer. Are byte ranges useful outside big static file downloads? -Jim