Mailing List Archive

On Apr 27, 10:33am, Robert S. Thau wrote:
} Subject: Closing file descriptors...
> From owner-new-httpd@hyperreal.com Thu Apr 27 09:38:36 1995
> From: rst@ai.mit.edu (Robert S. Thau)
> Date: Thu, 27 Apr 95 10:33:02 EDT
> Message-Id: <9504271433.AA07843@volterra>
> To: new-httpd@mail.apache.org
> Subject: Closing file descriptors...
>
> Paul Phillips has just noted that the file descriptors for the log files
> are left open in NCSA 1.3, which might allow a malicious CGI script to
> cover its tracks or wipe the log files entirely. It might be best to
> just close all descriptors except for stdin, stdout, and stderr before
> the exec() in cgi_stub(). The again, stderr is generally set to the
> error log, and I generally consider that a feature, rather than a bug
> (if a script screws up, you generally get useful info in the error_log).
> Any thoughts?
>
> rst
>
}-- End of excerpt from Robert S. Thau

Perhaps we (NCSA) should consider closing the other logs, but
I think there is value in allowing the script access to the
error log. In general my attitude toward malicious CGI scripts
is that the same care should be taken when installing new scripts
as is taken when installing new commands on your machine. You
shouldn't blindly download and run new executables or scripts.
I consider malicious scripts as less likely and therefore we
direct less effort in server development toward protecting against
them.

One final note on R1.3 - It is becoming an increasing burden to
support and proof it against attacks. The plan is to cease making
it (and all previous versions) available one month after 1.4 is
released. Is this going to cause problems for the Apache group?

-Beth
efrank@ncsa.uiuc.edu

On Apr 27, 10:33am, Robert S. Thau wrote:
} Subject: Closing file descriptors...
> From owner-new-httpd@hyperreal.com Thu Apr 27 09:38:36 1995
> From: rst@ai.mit.edu (Robert S. Thau)
> Date: Thu, 27 Apr 95 10:33:02 EDT
> Message-Id: <9504271433.AA07843@volterra>
> To: new-httpd@mail.apache.org
> Subject: Closing file descriptors...
>
> Paul Phillips has just noted that the file descriptors for the log files
> are left open in NCSA 1.3, which might allow a malicious CGI script to
> cover its tracks or wipe the log files entirely. It might be best to
> just close all descriptors except for stdin, stdout, and stderr before
> the exec() in cgi_stub(). The again, stderr is generally set to the
> error log, and I generally consider that a feature, rather than a bug
> (if a script screws up, you generally get useful info in the error_log).
> Any thoughts?
>
> rst
>
}-- End of excerpt from Robert S. Thau

Perhaps we (NCSA) should consider closing the other logs, but
I think there is value in allowing the script access to the
error log. In general my attitude toward malicious CGI scripts
is that the same care should be taken when installing new scripts
as is taken when installing new commands on your machine. You
shouldn't blindly download and run new executables or scripts.
I consider malicious scripts as less likely and therefore we
direct less effort in server development toward protecting against
them.

One final note on R1.3 - It is becoming an increasing burden to
support and proof it against attacks. The plan is to cease making
it (and all previous versions) available one month after 1.4 is
released. Is this going to cause problems for the Apache group?

-Beth
efrank@ncsa.uiuc.edu

I think there are a lot worse things a malicious CGI script
can do. This may not be a bad idea anyway though. I doubt
it adds any security though. Access to CGIs means a high level
of trust to your users.

Cliff
On Apr 27, 10:33am, Robert S. Thau wrote:
} Subject: Closing file descriptors...
} Paul Phillips has just noted that the file descriptors for the log files
} are left open in NCSA 1.3, which might allow a malicious CGI script to
} cover its tracks or wipe the log files entirely. It might be best to
} just close all descriptors except for stdin, stdout, and stderr before
} the exec() in cgi_stub(). The again, stderr is generally set to the
} error log, and I generally consider that a feature, rather than a bug
} (if a script screws up, you generally get useful info in the error_log).
} Any thoughts?
}
} rst
}-- End of excerpt from Robert S. Thau

I think there are a lot worse things a malicious CGI script
can do. This may not be a bad idea anyway though. I doubt
it adds any security though. Access to CGIs means a high level
of trust to your users.

Cliff
On Apr 27, 10:33am, Robert S. Thau wrote:
} Subject: Closing file descriptors...
} Paul Phillips has just noted that the file descriptors for the log files
} are left open in NCSA 1.3, which might allow a malicious CGI script to
} cover its tracks or wipe the log files entirely. It might be best to
} just close all descriptors except for stdin, stdout, and stderr before
} the exec() in cgi_stub(). The again, stderr is generally set to the
} error log, and I generally consider that a feature, rather than a bug
} (if a script screws up, you generally get useful info in the error_log).
} Any thoughts?
}
} rst
}-- End of excerpt from Robert S. Thau

On Thu, 27 Apr 1995, Robert S. Thau wrote:
> Paul Phillips has just noted that the file descriptors for the log files
> are left open in NCSA 1.3, which might allow a malicious CGI script to
> cover its tracks or wipe the log files entirely. It might be best to
> just close all descriptors except for stdin, stdout, and stderr before
> the exec() in cgi_stub(). The again, stderr is generally set to the
> error log, and I generally consider that a feature, rather than a bug
> (if a script screws up, you generally get useful info in the error_log).
> Any thoughts?

+1 - can't the error log be opened as append-only?

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/

On Thu, 27 Apr 1995, Robert S. Thau wrote:
> Paul Phillips has just noted that the file descriptors for the log files
> are left open in NCSA 1.3, which might allow a malicious CGI script to
> cover its tracks or wipe the log files entirely. It might be best to
> just close all descriptors except for stdin, stdout, and stderr before
> the exec() in cgi_stub(). The again, stderr is generally set to the
> error log, and I generally consider that a feature, rather than a bug
> (if a script screws up, you generally get useful info in the error_log).
> Any thoughts?

+1 - can't the error log be opened as append-only?

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/

The trouble with close-on-exec is that you have to remember to do it
to *everything* --- including stuff that the library may have opened
behind your back which you don't necessarily want to keep open. If
you go through the trouble of tracking down everything, they are, in
principle, equivalent, but

for (fd = 3; fd < max; ++fd) close(fd);

is a lot more swift and sure...

rst

The trouble with close-on-exec is that you have to remember to do it
to *everything* --- including stuff that the library may have opened
behind your back which you don't necessarily want to keep open. If
you go through the trouble of tracking down everything, they are, in
principle, equivalent, but

for (fd = 3; fd < max; ++fd) close(fd);

is a lot more swift and sure...

rst

Swift...even if you have set your system up to have thousands of
file descriptor per process? This is a known bug in sendmail that it
does this and gets boged down. This is a very suboptimal hack.
It's really only a problem for files you have write permission to,
who cares about the rest? And if you did care you'd know what they
were and close them.

Apache can't provide a safe enviornment for CGI's, it's simply
not doable.


On Apr 27, 2:18pm, Robert S. Thau wrote:
} Subject: Re: Closing file descriptors...
} The trouble with close-on-exec is that you have to remember to do it
} to *everything* --- including stuff that the library may have opened
} behind your back which you don't necessarily want to keep open. If
} you go through the trouble of tracking down everything, they are, in
} principle, equivalent, but
}
} for (fd = 3; fd < max; ++fd) close(fd);
}
} is a lot more swift and sure...
}
} rst
}-- End of excerpt from Robert S. Thau

From: efrank@ncsa.uiuc.edu (Elizabeth Frank)
Date: Thu, 27 Apr 1995 10:14:59 -0500

One final note on R1.3 - It is becoming an increasing burden to
support and proof it against attacks. The plan is to cease making
it (and all previous versions) available one month after 1.4 is
released. Is this going to cause problems for the Apache group?

We all have copies ;-). The main issue for us concerning NCSA
handling of the 1.3 code has always been the question of legal title
(it would be nice if 1.3R+ had the legal notices in the source code,
to eliminate that ambiguity, but we can live with the status quo).

Incidentally, speaking of the burden of supporting 1.3... Now that the
/foo.cgi/ security hole is public knowledge (viz. recent posts on
comp.infosystems.www.servers.unix), you might want to release a
non-beta server which fixes that problem (either 1.4 final or another
spin on 1.3 --- but there ought to be something).

Anyway, thanks for asking...

rst

From: efrank@ncsa.uiuc.edu (Elizabeth Frank)
Date: Thu, 27 Apr 1995 10:14:59 -0500

One final note on R1.3 - It is becoming an increasing burden to
support and proof it against attacks. The plan is to cease making
it (and all previous versions) available one month after 1.4 is
released. Is this going to cause problems for the Apache group?

We all have copies ;-). The main issue for us concerning NCSA
handling of the 1.3 code has always been the question of legal title
(it would be nice if 1.3R+ had the legal notices in the source code,
to eliminate that ambiguity, but we can live with the status quo).

Incidentally, speaking of the burden of supporting 1.3... Now that the
/foo.cgi/ security hole is public knowledge (viz. recent posts on
comp.infosystems.www.servers.unix), you might want to release a
non-beta server which fixes that problem (either 1.4 final or another
spin on 1.3 --- but there ought to be something).

Anyway, thanks for asking...

rst

>Paul Phillips has just noted that the file descriptors for the log files
>are left open in NCSA 1.3, which might allow a malicious CGI script to
>cover its tracks or wipe the log files entirely. It might be best to
>just close all descriptors except for stdin, stdout, and stderr before
>the exec() in cgi_stub(). The again, stderr is generally set to the
>error log, and I generally consider that a feature, rather than a bug
>(if a script screws up, you generally get useful info in the error_log).
>Any thoughts?

I tried to do this with the nscache file descriptors, by marking them
close on exec. (Though this causes problems on NeXT; investigations underway.)

I think it would be appropriate to do this for the other file descriptors.

David.

>Paul Phillips has just noted that the file descriptors for the log files
>are left open in NCSA 1.3, which might allow a malicious CGI script to
>cover its tracks or wipe the log files entirely. It might be best to
>just close all descriptors except for stdin, stdout, and stderr before
>the exec() in cgi_stub(). The again, stderr is generally set to the
>error log, and I generally consider that a feature, rather than a bug
>(if a script screws up, you generally get useful info in the error_log).
>Any thoughts?

I tried to do this with the nscache file descriptors, by marking them
close on exec. (Though this causes problems on NeXT; investigations underway.)

I think it would be appropriate to do this for the other file descriptors.

David.