Re: [PATCH] call hook from sig_coredump
Justin Erenkrantz wrote: --On Wednesday, February 19, 2003 2:12 PM -0500 Jeff Trawick wrote: The attached patch changes sig_coredump to call a hook. In the fullness of time, the ap_exception_info_t provided to the hook would contain any and all relevant information available to a signal/exception handler (e.g., siginfo_t on many Unix variants). Here's a compromise that I'd be willing to accept: you have to explictly enable this hook at configure-time. Otherwise, this hook won't be executed on a signal. Does anybody agree with Justin's compromise (i.e., if I put more effort into this direction am I going to find out that somebody doesn't think the compromise is conservative enough :) )?
Re: [PATCH] call hook from sig_coredump
At 12:30 PM 3/3/2003, Bill Stoddard wrote: Jeff Trawick wrote: Justin Erenkrantz wrote: --On Wednesday, February 19, 2003 2:12 PM -0500 Jeff Trawick wrote: The attached patch changes sig_coredump to call a hook. In the fullness of time, the ap_exception_info_t provided to the hook would contain any and all relevant information available to a signal/exception handler (e.g., siginfo_t on many Unix variants). Here's a compromise that I'd be willing to accept: you have to explictly enable this hook at configure-time. Otherwise, this hook won't be executed on a signal. Does anybody agree with Justin's compromise (i.e., if I put more effort into this direction am I going to find out that somebody doesn't think the compromise is conservative enough :) )? I don't like the idea of enabling this hook at configure time. Why not add the hook and leave it to modules whether they want to use it or not? Because it is a potential security hole? The only individual who should choose to expose or prevent the hole would be the administrator who installs (and therefore probably built) Apache. I don't see the value in crufting up configure more that it already is. Can we piggy-back such features into a single --unwise-but-useful configure option? Bill
Re: [PATCH] call hook from sig_coredump
William A. Rowe, Jr. wrote: At 12:30 PM 3/3/2003, Bill Stoddard wrote: Jeff Trawick wrote: Justin Erenkrantz wrote: --On Wednesday, February 19, 2003 2:12 PM -0500 Jeff Trawick wrote: The attached patch changes sig_coredump to call a hook. In the fullness of time, the ap_exception_info_t provided to the hook would contain any and all relevant information available to a signal/exception handler (e.g., siginfo_t on many Unix variants). Here's a compromise that I'd be willing to accept: you have to explictly enable this hook at configure-time. Otherwise, this hook won't be executed on a signal. Does anybody agree with Justin's compromise (i.e., if I put more effort into this direction am I going to find out that somebody doesn't think the compromise is conservative enough :) )? I don't like the idea of enabling this hook at configure time. Why not add the hook and leave it to modules whether they want to use it or not? Because it is a potential security hole? The only individual who should choose to expose or prevent the hole would be the administrator who installs (and therefore probably built) Apache. That same admin controls which modules are loaded as well. I don't see the value in crufting up configure more that it already is. Can we piggy-back such features into a single --unwise-but-useful configure option? Obviously not. If it is -really- unwise, then we should just not do it. I see no evidence that is the case though. How, exactly, could this hook be remotely and uniquely exploited? Bill
Re: [PATCH] call hook from sig_coredump
--On Monday, March 3, 2003 2:14 PM -0500 Bill Stoddard [EMAIL PROTECTED] wrote: Obviously not. If it is -really- unwise, then we should just not do it. I see no evidence that is the case though. How, exactly, could this hook be remotely and uniquely exploited? We need to keep our signal handling code to a minimum since we can make no assumptions about the system integrity once we enter such routines. Allowing a hook to always be run by default seems like asking for trouble (because it'd be a global structure that might be susceptible to being maliciously overwritten). We've had strong recommendations from security types in the past to remove sig_coredump entirely. -- justin
Re: [PATCH] call hook from sig_coredump
At 01:14 PM 3/3/2003, Bill Stoddard wrote: William A. Rowe, Jr. wrote: At 12:30 PM 3/3/2003, Bill Stoddard wrote: I don't like the idea of enabling this hook at configure time. Why not add the hook and leave it to modules whether they want to use it or not? Because it is a potential security hole? The only individual who should choose to expose or prevent the hole would be the administrator who installs (and therefore probably built) Apache. That same admin controls which modules are loaded as well. And they psychically know that a module is using this hook, or not, as the case may be? I rather like the permit this or not level of control by the Administrator, without relying on module authors. The paranoid Admin is unlikely to trust either the application or loadable modules anyways, so giving them as many overrides as possible to reduce exploitable behavior is goodness. I don't see the value in crufting up configure more that it already is. Can we piggy-back such features into a single --unwise-but-useful configure option? Obviously not. If it is -really- unwise, then we should just not do it. I see no evidence that is the case though. How, exactly, could this hook be remotely and uniquely exploited? Code running post-segv after a stack overflow is subject to any number of 'side-effects', Mark could provide better pointers to exploit code than I can. IIUC you propose this hook in the child that is segfaulting. If I've misunderstood and this is code in the parent after the child segfaults, ignore my musings. Bill
Re: [PATCH] call hook from sig_coredump
At 02:12 PM 3/3/2003, Justin Erenkrantz wrote: --On Monday, March 3, 2003 2:14 PM -0500 Bill Stoddard [EMAIL PROTECTED] wrote: Obviously not. If it is -really- unwise, then we should just not do it. I see no evidence that is the case though. How, exactly, could this hook be remotely and uniquely exploited? We need to keep our signal handling code to a minimum since we can make no assumptions about the system integrity once we enter such routines. Allowing a hook to always be run by default seems like asking for trouble (because it'd be a global structure that might be susceptible to being maliciously overwritten). We've had strong recommendations from security types in the past to remove sig_coredump entirely. -- justin Maybe that's the answer. One compile flag to eliminate the segv handler altogether, along with the proposed hook, or keep segv handling along with the hook. --segv-handler=enable|disable ??? No need for an in between 'one but not the other', at least I don't believe. Bill
Re: [PATCH] call hook from sig_coredump
William A. Rowe, Jr. wrote: At 02:12 PM 3/3/2003, Justin Erenkrantz wrote: We've had strong recommendations from security types in the past to remove sig_coredump entirely. -- justin Maybe that's the answer. One compile flag to eliminate the segv handler altogether, along with the proposed hook, or keep segv handling along with the hook. --segv-handler=enable|disable ??? so at startup we'd then have to chdir to whatever was specified by CoredumpDirectory...
Re: [PATCH] call hook from sig_coredump
On Wed, 19 Feb 2003, Jeff Trawick wrote: The attached patch changes sig_coredump to call a hook. In the fullness of time, the ap_exception_info_t provided to the hook would contain any and all relevant information available to a signal/exception handler (e.g., siginfo_t on many Unix variants). ... Thoughts/concerns? Why do I fear this would be a security problem waiting to happen? :-/ --Cliff
Re: [PATCH] call hook from sig_coredump
--On Wednesday, February 19, 2003 2:33 PM -0500 Cliff Woolley [EMAIL PROTECTED] wrote: On Wed, 19 Feb 2003, Jeff Trawick wrote: The attached patch changes sig_coredump to call a hook. In the fullness of time, the ap_exception_info_t provided to the hook would contain any and all relevant information available to a signal/exception handler (e.g., siginfo_t on many Unix variants). ... Thoughts/concerns? Why do I fear this would be a security problem waiting to happen? :-/ I was thinking the same thing. Executing code after a SEGV (or other coredump situation) seems risky. -- justin
Re: [PATCH] call hook from sig_coredump
Cliff Woolley wrote: On Wed, 19 Feb 2003, Jeff Trawick wrote: The attached patch changes sig_coredump to call a hook. In the fullness of time, the ap_exception_info_t provided to the hook would contain any and all relevant information available to a signal/exception handler (e.g., siginfo_t on many Unix variants). ... Thoughts/concerns? Why do I fear this would be a security problem waiting to happen? :-/ I can't guess. Assume that we have a bug such that a malicious user can cause us to segfault at will. If some module implements the fatal exception hook then what are you afraid that it will do that it couldn't have done in any other hook?
Re: [PATCH] call hook from sig_coredump
Cliff Woolley wrote: On Wed, 19 Feb 2003, Jeff Trawick wrote: The attached patch changes sig_coredump to call a hook. In the fullness of time, the ap_exception_info_t provided to the hook would contain any and all relevant information available to a signal/exception handler (e.g., siginfo_t on many Unix variants). ... Thoughts/concerns? Why do I fear this would be a security problem waiting to happen? :-/ Foresight :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
