XSS vulnerability in mod_negotiation - status in 2.2.8?
Greetings, Our security guy noticed this alert about a XSS vulnerability in mod_negotiation: http://www.mindedsecurity.com/MSA01150108.html. According to the link, it applies to apache = 2.2.6, so no worries for 2.2.8. However, when I double-check the changelog for 2.2.8 (http://www.apache.org/dist/httpd/CHANGES_2.2.8) there is no specific mention of a patch in mod_negotiation... From a quick inspection of the source code, there was no change to mod_negotiation.c between 2.2.6 and 2.2.8 so can I conclude that the vulnerability is still present in 2.2.8? (ie, can it have been handled at a higher level?) Rgds, Owen Boyle Disclaimer: Any disclaimer attached to this message may be ignored. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. The sender's company reserves the right to monitor all e-mail communications through their networks.
Re: PR42829: graceful restart with multiple listeners using prefork MPM can result in hung processes
On Fri, Feb 01, 2008 at 10:41:39AM +0100, Stefan Fritsch wrote: Joe Orton wrote: I mentioned in the bug that the signal handler could cause undefined behaviour, but I'm not sure now whether that is true. On Linux I can reproduce some cases where this will happen, which are all due to well-defined behaviour: 1) with some (default on Linux) accept mutex types, apr_proc_mutex_lock() will loop on EINTR. Hence, children blocked waiting for the mutex do hang until the mutex is released. Fixing this would need some APR work, new interfaces, blah This is not a problem. On graceful-stop or reload the processes will get the lock one by one and die (or hang somewhere else). I have never seen a left over process hanging in this function. Well, normally all children will be woken up and take the accept mutex because of the dummy connections. But if you have one child blocked because of issue (3) - whilst holding the accept mutex - all the other children will also be blocked. If the EINTR could be processed at MPM level, this wouldn't happen. So I think it is a problem, though you could argue that solving (3) also sort of solves (1). I can also reproduce a third case, but I'm not sure about the cause: 3) apr_pollset_poll() is blocking despite the fact that the listening fds are supposedly already closed before entering the syscall. This is the main problem in my experience. ... On Linux with epoll, the hanging processes just blocks in apr_pollset_poll(), so checking the return value won't do any good. Maybe the problem is that (AIUI) poll() returns POLLNVAL if a fd is not open, while epoll() does not have something similar. In epoll.c, a comment says APR_POLLNVAL is not handled by epoll. Or should epoll return EPOLLHUP in this case? I did some more research on this: the case is covered in the epoll(7) man page - fds are removed from any containing epoll sets on closure. So it is well-defined behaviour, and the hang is expected; when all the listeners are closed, the poll set becomes empty, so the apr_pollset_poll() call will sleep forever, or until interrupted by signal! select() and poll() will indeed return POLLNVAL for the closed-fds case, and prefork needs to check for that. From some brief googling, FreeBSD kqueue appears to have the same guarantee. This PR has some investigation of what happens with Solaris ports: http://issues.apache.org/bugzilla/show_bug.cgi?id=42580 For the graceful-stop case, it would be simple enough to just signal any dozy children again to wake them up in the wait-for-exit loop, but graceful-restart doesn't have that opportunity, so I'm not sure about a general solution. Reducing the poll timeout to some non-infinite time would work. joe
Re: XSS vulnerability in mod_negotiation - status in 2.2.8?
On Feb 5, 2008 5:40 AM, Boyle Owen [EMAIL PROTECTED] wrote: Greetings, Our security guy noticed this alert about a XSS vulnerability in mod_negotiation: http://www.mindedsecurity.com/MSA01150108.html. According to the link, it applies to apache = 2.2.6, so no worries for 2.2.8. However, when I double-check the changelog for 2.2.8 (http://www.apache.org/dist/httpd/CHANGES_2.2.8) there is no specific mention of a patch in mod_negotiation... From a quick inspection of the source code, there was no change to mod_negotiation.c between 2.2.6 and 2.2.8 so can I conclude that the vulnerability is still present in 2.2.8? (ie, can it have been handled at a higher level?) If I remember correctly, the security does not consider this a vulnerability. To do the XSS you need control of filenames on the server. If you have that, you probably have much-more-straightforward ways to steal cookies. There might be a very-few badly-configured sites that are vulnerable to this, so it should be fixed. But it is not a serious security issue. Joshua.
Re: XSS vulnerability in mod_negotiation - status in 2.2.8?
Joshua Slive wrote: On Feb 5, 2008 5:40 AM, Boyle Owen [EMAIL PROTECTED] wrote: Greetings, Our security guy noticed this alert about a XSS vulnerability in mod_negotiation: http://www.mindedsecurity.com/MSA01150108.html. According to the link, it applies to apache = 2.2.6, so no worries for 2.2.8. The author of that post was already advised this isn't a vulnerability. As they want egg on their face for flailing their arms about, surely you aren't surprised their notes wouldn't otherwise be correct with respect to the applicable version, are you? If I remember correctly, the security does not consider this a vulnerability. To do the XSS you need control of filenames on the server. If you have that, you probably have much-more-straightforward ways to steal cookies. Bingo. If you can create a file, you can author a XSS page. There simply is not a vulnerability here. There might be a very-few badly-configured sites that are vulnerable to this, so it should be fixed. But it is not a serious security issue. Disagree; it is a flaw, the names should be escaped, but there's absolutely no reason to fix this for 'vulnerable' sites, their misconfiguration is far more insidious if it has permit this, and it's considered an XSS in their context. Bill
store_headers in memcache and diskcache
Caching experts -- why do memcache and diskcache have seemingly quite different caching strategies when it comes to storing the headers ? E.g. the cache_object_t * is populated with the status/date/etc data in memcache - but not in disk-cache. Is this work in progress or subtle design ? I am trying to understand (got a working mod_memcached_cache.c* -- and cannot quite get the right VARY behaviour). Thanks, Dw. *: using apr_memcache and a bit more generalized glue as to reduce the overlap with the mod_ssl memcache backend. As to then be able to layer in (lib)ketama (robust hashing) and ultimately plug-able cache invalidation.
Re: store_headers in memcache and diskcache
On Tue, Feb 05, 2008 at 01:49:43PM -0500, Garrett Rooney wrote: On Feb 5, 2008 1:45 PM, Dirk-Willem van Gulik [EMAIL PROTECTED] wrote: Caching experts -- why do memcache and diskcache have seemingly quite different caching strategies when it comes to storing the headers ? E.g. the cache_object_t * is populated with the status/date/etc data in memcache - but not in disk-cache. Is this work in progress or subtle design ? I am trying to understand (got a working mod_memcached_cache.c* -- and cannot quite get the right VARY behaviour). If I had to guess I'd say it's because people have actually been working on disk cache, while mem cache has been largely ignored for a while. Definitely! I remember the original patches tried to create some nice abstractions so that more logic would move into mod_cache propery than in mod_*_cache, but there turned out to be so many corner cases within mod_disk_cache itself - and noone seems to /use/ mod_mem_cache - that that fell by the wayside :/ -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: store_headers in memcache and diskcache
On Feb 5, 2008 1:45 PM, Dirk-Willem van Gulik [EMAIL PROTECTED] wrote: Caching experts -- why do memcache and diskcache have seemingly quite different caching strategies when it comes to storing the headers ? E.g. the cache_object_t * is populated with the status/date/etc data in memcache - but not in disk-cache. Is this work in progress or subtle design ? I am trying to understand (got a working mod_memcached_cache.c* -- and cannot quite get the right VARY behaviour). If I had to guess I'd say it's because people have actually been working on disk cache, while mem cache has been largely ignored for a while. -garrett
Re: mod_proxy timeouts
It seems like mod_proxy has gone through a lot of changes in 2.2, including changes to handling of timeouts. I brought up my initial concerns about the handling of ProxyTimeout on the [EMAIL PROTECTED] list and got absolutely no response. :( Perhaps a patch will get a little more interest there so I'll go ahead and try. Ron On Mon, 2008-02-04 at 17:12 -0500, Eric Covener wrote: On Feb 4, 2008 4:39 PM, Ronald Park [EMAIL PROTECTED] wrote: According to the description of the ProxyTimeout directive, this is the expected behavior: I think this is more OT at [EMAIL PROTECTED], but you should verify the state of affairs in trunk and 2.2.x first. There has been work on this issue.
Re: store_headers in memcache and diskcache
On Feb 5, 2008, at 7:58 PM, Colm MacCarthaigh wrote: On Tue, Feb 05, 2008 at 01:49:43PM -0500, Garrett Rooney wrote: On Feb 5, 2008 1:45 PM, Dirk-Willem van Gulik [EMAIL PROTECTED] wrote: Caching experts -- why do memcache and diskcache have seemingly quite different caching strategies when it comes to storing the headers ? E.g. the cache_object_t * is populated with the status/date/etc data in memcache - but not in disk-cache. Is this work in progress or subtle design ? I am trying to understand (got a working mod_memcached_cache.c* -- and cannot quite get the right VARY behaviour). If I had to guess I'd say it's because people have actually been working on disk cache, while mem cache has been largely ignored for a while. Definitely! I remember the original patches tried to create some nice abstractions so that more logic would move into mod_cache propery than in mod_*_cache, but there turned out to be so many corner cases within mod_disk_cache itself - and noone seems to /use/ mod_mem_cache - that that fell by the wayside :/ Thanks ! That is useful info -- so for now I'll focus on mod_disk_cache -- and once I got that mapped to mod_memcached -- will then see if we can abstract that into a cleaner mod_memcache. But first priority is getting it clean-ish/same-ish relative to the ssl use of memcached (my usecase is OpenID -- which is 'heavy' on both). Dw
mod_proxy timeouts in the 2.0
The problem and patch in the below message are in regards to just the Apache 2.0 line; it seems like a number of improvements in timeout handling have already been implemented in the 2.2 version of mod_proxy. However, also included in my patch is a mechanism to provide even more granularity in timeouts by setting it via an environment var: I have not done the work though to find an implementation in the 2.2 line though but if there is an interest, I could investigate it. On to my problem and a possible patch: According to the description of the ProxyTimeout directive, this is the expected behavior of that directive: This directive allows a user to specifiy a timeout on proxy requests. This is useful when you have a slow/buggy appserver which hangs, and you would rather just return a timeout and fail gracefully instead of waiting however long it takes the server to return. However, this is not what occurs. The ProxyTimeout is only used to obtain the connection to the 'origin server'; when it actually sends the proxied request and waits for the response, the value of the Timeout directive is used. Unfortunately, mod_proxy uses a core function called 'pre_connection' after the connection has been made (despite the 'pre' in the function name :D) and therein lies the problem. That code only has access to the server config, not the modules configs, and it resets the timeout to the value of the Timeout directive. My fix is to reset the timeout *after* the call to pre_connection if this directive is set. I also added new functionality allowing a special environment variable (proxy-timeout) to be set to overload the directive for more fine-grained control. This would allow the following: ProxyTimeout 15 RewriteRule ^/proxy/(.*)$ http://someotherserver.com/$1 RewriteRule ^/quick/(.*)$ http://someotherserver.com/$1 \ [E=proxy-timeout:5] RewriteRule ^/slow/(.*)$ http://someotherserver.com/$1 \ [E=proxy-timeout:30] This allows three different proxies timeouts to the same origin server (someotherserver.com) based on the URL to the forward proxy. Attached is my patch to 2.0.63 to the proxy_http.c file in modules/proxy. Thanks, Ron
Re: store_headers in memcache and diskcache
On 02/05/2008 07:45 PM, Dirk-Willem van Gulik wrote: Caching experts -- why do memcache and diskcache have seemingly quite different caching strategies when it comes to storing the headers ? E.g. the cache_object_t * is populated with the status/date/etc data in memcache - but not in disk-cache. Is this work in progress or subtle design ? But mod_mem_cache never restores the status (see comment mod_cache.c:288) :-). I think the difference is because cache_object_t is the data structure that mod_mem_cache actually stores in the cache to keep this data (in fact a pointer to the cache_info data) around whereas mod_disk_cache serializes the cache_info from cache_object_t data and writes it to disk. Once mod_disk_cache reads back the data from the disk it populates the cache_info field in cache_object_t again with the deserialized data (see open_entity and file_cache_recall_mydata). I am trying to understand (got a working mod_memcached_cache.c* -- and cannot quite get the right VARY behaviour). As others mentioned mod_mem_cache did not receive the same love as mod_disk_cache. So I am not quite sure if VARY even works correctly with mod_mem_cache. Regards Rüdiger
Re: PCRE pcreposix.h header missing from Apache 2.2 downloads
On Feb 4, 2008 1:20 PM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Arfrever Frehtes Taifersar Arahesis wrote: 2008-02-04 20:41:47 David McCreedy napisał(a): It seems that the pcreposix.h header file, which pcreposix.c includes, isn't in the Apache 2.2 source tree. But I can find it in Apache 2.0 and that version appears to work OK with 2.2's pcreposix.c. Is the operating system now assumed to have a pcreposix.h header? Or maybe pcreposix.h is auto-generated and I'm just not seeing it? Or is it really missing? And can it be added back? See http://svn.apache.org/viewvc?view=revrevision=153384 Thanks. I think I understand now. -David
