Tony Finch [EMAIL PROTECTED] writes:
Apache itself has support for setting resource limits, although I
agree that in many cases you may want them to be different between the
httpd and the CGIs.
You most emphatically do not want to do that. You want the CGI to run
with its owner's resource
A jailed environment will certainly help prevent them from breaking
root, but keep in mind that the server side scripts already need to
have read (and probably write) access to much of the data associated
with the web site in order to operate the web site. You can do only
so
Matt Dillon [EMAIL PROTECTED] writes:
The real problem here is the CGI script / server-side design allowing
the breakin in the first place.
That's not a fixable problem when the customer is meant to provide his
own scripts. I've worked on such a scenario before; we managed to
chroot
I've said it before, and I'll say it again:
http://www.FreeBSD.org/cgi/query-pr.cgi?pr=13606
Tony Finch [EMAIL PROTECTED] writes:
Apache itself has support for setting resource limits, although I
agree that in many cases you may want them to be different between the
httpd and the
On Tue, 16 Jan 2001, Michael R. Wayne wrote:
Background:
We recently had a customer's web site suffer an attempted exploit
via one of their cgi scripts. The attempted exploit involved
writing a file into /tmp, then invoking inetd with that file to
get a root shell on a
Gordon Tetlow [EMAIL PROTECTED] writes:
If you are using apache (who isn't?), I highly suggest you look into using
suexec. That way bad CGI programming is offloaded to the customer and not
to your system.
suexec has many weaknesses - amongst other problems, it does not set
resource limits;
Dag-Erling Smorgrav [EMAIL PROTECTED] wrote:
Gordon Tetlow [EMAIL PROTECTED] writes:
If you are using apache (who isn't?), I highly suggest you look into using
suexec. That way bad CGI programming is offloaded to the customer and not
to your system.
suexec has many weaknesses - amongst other
On Wed, Jan 17, 2001 at 07:47:23AM +0100, Walter W. Hop wrote:
The exploit managed to start inetd, camped on the specified port
I guess, if it doesn't exist already, that it wouldn't be so hard to
create a small patch to the kernel, so that only processes owned by root,
or a certain
On Wed, Jan 17, 2001 at 10:33:30AM +0200, Peter Pentchev wrote:
I've actually been thinking along the lines of something like that.
A bit more strict access control though - bind() on AF_INET and/or AF_INET6
disabled by default, except for certain uid/sockaddr pairs. A kernel module
keeping
On Wed, Jan 17, 2001 at 10:17:03AM +, David Malone wrote:
On Wed, Jan 17, 2001 at 10:33:30AM +0200, Peter Pentchev wrote:
I've actually been thinking along the lines of something like that.
A bit more strict access control though - bind() on AF_INET and/or AF_INET6
disabled by
"Michael R. Wayne" wrote:
Recommendation:
A number of the executables located in /sbin and /usr/sbin are
never going to be invoked for any legitimate use by anyone other
than the superuser. In particular, servers such as portmap and
inetd run by non-root users are unlikely to
Peter Pentchev writes:
On Wed, Jan 17, 2001 at 07:47:23AM +0100, Walter W. Hop wrote:
The exploit managed to start inetd, camped on the specified port
I guess, if it doesn't exist already, that it wouldn't be so hard to
create a small patch to the kernel, so that only processes
At 07:47 17/01/01 +0100, Walter W. Hop wrote:
The exploit managed to start inetd, camped on the specified port
I guess, if it doesn't exist already, that it wouldn't be so hard to
create a small patch to the kernel, so that only processes owned by root,
or a certain group of users (let's
Background:
We recently had a customer's web site suffer an attempted exploit
via one of their cgi scripts. The attempted exploit involved
writing a file into /tmp, then invoking inetd with that file to
get a root shell on a non-standard port. While the exploit
failed, they were
Recommendation:
A number of the executables located in /sbin and /usr/sbin are
never going to be invoked for any legitimate use by anyone other
than the superuser. In particular, servers such as portmap and
inetd run by non-root users are unlikely to do what was intended.
It
The exploit managed to start inetd, camped on the specified port
I guess, if it doesn't exist already, that it wouldn't be so hard to
create a small patch to the kernel, so that only processes owned by root,
or a certain group of users (let's say "daemon"), were allowed to set up
16 matches
Mail list logo
