Hi,
I just stumbled over this threat and think we see the effects of this
bug in the "real world". We're currently porting a medium sized
Web application from Apache 1.3 and mod_perl 1 to Apache 2.0
and mod_perl 2. The application is mostly written in Mason.
The first strange behaviour we encountered was that
authentication using mod_authnz_external would fail intermittently.
mod_authnz_external does authentication by invoking an
external program (presumably running setuid), passing it the
remote user user and password and interpreting the program's exit
code. I traced system calls for the Apache processes and
file descriptor 0 in the Apache process would sometimes be closed
when mod_authnz_external was invoked. It basically works like this
(note that the external_prog expects user+password on its stdin):
pipe(rd, wr);
if (!(pid = fork())) {
// child
close(wr);
dup2(rd, 0);
close(rd);
execve(external_prog,...)
}
// parent
close(rd);
write(wr, "user\npassword\n");
wait(pid);
Now, if file descriptor 0 is closed prior to the pipe call then rd = 0,
dup2(rd, 0) is a no-op and close(rd) closes stdin. The external program
inherits this closed stdin and will fail.
At that point I just accepted the fact that stdin may be closed in an
Apache process and patched mod_authnz_external to skip dup2/close when
rd == 0 already.
Later on, we discovered other failures with mod_authnz_external that
were similarly caused by a closed file descriptor 1 prior to its call.
We also have still unexplained intermittent problems to capture the
stdout of external programs run (with system()) from Mason scripts.
I suspect the reason may also be closed file descriptors 0, 1, or 2.
Our Apache only serves static content, some classic CGI scripts
and lots of Mason pages (i.e. we only deal with mod_perl indirectly
thru Mason) and uses only standard Apache modules except for
mod_authnz_external. I can ruled out the letter to cause this
file descriptor corruption and a pristine Apache process has fd 0 and fd 1
on /dev/null and f2 on its error_log as expected.
Cheers, Roderich
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
