Re: Protections on inetd (and /sbin/* /usr/sbin/* in general)
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 limits. I expect chrooting was left out because people who have the wit to set up a chroot are capable of adding a couple of lines to a C program. Said program has a big fat warning at the top that says something like "do not ever change this program, you'll only screw it up"... I'm tempted to reply "not much more than it already is". Eivind and I rewrote it for our previous employer, but the mod is part of a large chunk of proprietary code, unfortunately. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Protections on inetd (and /sbin/* /usr/sbin/* in general)
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 much. The real problem here is the CGI script / server-side design allowing the breakin in the first place. The KISS principle applies. Good programming practices (such as using the likes of asprintf() and snprintf() instead of sprintf() in C), and code auditing, pretty much removes the chance of an exploit. For C based CGI's you need only do a few things to reduce the errors down into nothing more then null-pointer derferences which generally cannot be exploited. It means not making any assumptions whatsoever on the size or content of input data, even if you have client-side javascript 'restricting' the content of the input data. It also means properly escaping all POST data so when someone types 'Bfubar/B' into an input field the worst that happens is for it to show up as 'Bfubar/B' in any HTML output rather then FUBAR (bolded 'fubar'). How often have you typed a single quote into an sql-database-backed web page input field and gotten a fault? A backslash? Punctuation? Hmm proper escaping is absolutely mandatory. It also means not trusting input data... properly massaging it before using it for things like, oh, command line arguments to exec'd programs, and stupid things like that. Some languages are less likely to be exploitable then others, but never assume that the scripting / programming language will protect you. After all, again, if the backend needs to access the data to drive the site then exploits can potentially also access the data, no matter what kind of security measures are taken in the language imlementation. If the backend needs to store persistent state, then exploits can also potentially modify that state. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Protections on inetd (and /sbin/* /usr/sbin/* in general)
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 the scripts so we're reasonably confident that they can't do much harm except to themselves. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Protections on inetd (and /sbin/* /usr/sbin/* in general)
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 CGIs.
You most emphatically do not want to do that. You want the CGI to run
with its owner's resource limits.
I expect chrooting was left out because people who have the wit to set
up a chroot are capable of adding a couple of lines to a C program.
Said program has a big fat warning at the top that says something like
"do not ever change this program, you'll only screw it up"... I'm
tempted to reply "not much more than it already is". Eivind and I
rewrote it for our previous employer, but the mod is part of a large
chunk of proprietary code, unfortunately.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
--
:{ [EMAIL PROTECTED]
Andy Farkas
System Administrator
Speednet Communications
http://www.speednet.com.au/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Protections on inetd (and /sbin/* /usr/sbin/* in general)
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 non-standard port. While the exploit failed, they were able to write the file as user nobody and invoke inetd. There is not much we can do about that as long as we permit customers to use their own cgi scripts, which is a requirement with this type of account. 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. -gordon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Protections on inetd (and /sbin/* /usr/sbin/* in general)
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; nor does it chroot as far as I recall. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Protections on inetd (and /sbin/* /usr/sbin/* in general)
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 problems, it does not set resource limits; nor does it chroot as far as I recall. 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. I expect chrooting was left out because people who have the wit to set up a chroot are capable of adding a couple of lines to a C program. Tony. -- f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED] "Because all you of Earth are idiots!" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Protections on inetd (and /sbin/* /usr/sbin/* in general)
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 group of users (let's say "daemon"), were allowed to set up listeners... 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 a table of uid/sockaddr pairs, and a userland tool (bindcontrol?) to feed it the necessary data. Does this strike people as particularly useless? :) I can think of at least one situation where it would be useful - shell hosting with virtual hostnames, where people are only allowed to have stuff listen on addresses they themselves have registered. And yes, I know about jail, and it seems a bit too much of an overkill. G'luck, Peter -- When you are not looking at it, this sentence is in Spanish. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Protections on inetd (and /sbin/* /usr/sbin/* in general)
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 a table of uid/sockaddr pairs, and a userland tool (bindcontrol?) to feed it the necessary data. I think it would be very difficult to do this sensibly. You might be able to stop people listening on tcp ports, but if you stop people listening on UDP ports then DNS stops working. (Stopping people listening on TCP ports is also likely to break ssh, ftp and various other things - tough that may be desirable in the situation in question.) David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Protections on inetd (and /sbin/* /usr/sbin/* in general)
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 default, except for certain uid/sockaddr pairs. A kernel module keeping a table of uid/sockaddr pairs, and a userland tool (bindcontrol?) to feed it the necessary data. I think it would be very difficult to do this sensibly. You might be able to stop people listening on tcp ports, but if you stop people listening on UDP ports then DNS stops working. Yes, I know about the problems with UDP.. there are not too many undesirable things users may run on UDP though, so for the first approximation, I'd keep restrictions to TCP only. (Stopping people listening on TCP ports is also likely to break ssh, ftp and various other things - tough that may be desirable in the situation in question.) ftp has a passive mode; how exactly does this break ssh? (or do you mean connection forwarding?) Anyway, with a bit more thought, users may be allowed to bind to some kind of 'primary' address (hmm maybe the distinction between an interface address and interface alias could be applied here).. or just told 'tough!' :) G'luck, Peter -- When you are not looking at it, this sentence is in Spanish. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Protections on inetd (and /sbin/* /usr/sbin/* in general)
"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 do what was intended. It seems a prudent measure to simply not set execute permission by "other" on such programs during the install, giving the user a handy "Permission denied" message when such an attempt is made. For those reading quickly, I am NOT recommending removing execute permission on ALL of /sbin/* and /usr/sbin/*, only on programs such as "portmap", "inetd", "lpd", "syslogd", "halt", "reboot" and others which perform no useful function to normal users. /sbin/init already enforces this condition, how about expanding it? Setup jail instead. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] "There is no spoon." -- Kiki To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Protections on inetd (and /sbin/* /usr/sbin/* in general)
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 owned by root, or a certain group of users (let's say "daemon"), were allowed to set up listeners... 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 a table of uid/sockaddr pairs, and a userland tool (bindcontrol?) to feed it the necessary data. Does this strike people as particularly useless? :) I can think of at least one situation where it would be useful - shell hosting with virtual hostnames, where people are only allowed to have stuff listen on addresses they themselves have registered. And yes, I know about jail, and it seems a bit too much of an overkill. A kernel module developping instead of jail IS the overkill. jail is easy configurable (after 2nd or 3th of them) -- @BABOLO http://links.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Protections on inetd (and /sbin/* /usr/sbin/* in general)
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 say "daemon"), were allowed to set up listeners... just make IPPORT_RESERVED equal to 65535:) but then how will he be able to run an unprivileged http server? As it was said before, trying to change permissions, delete unnecessary binaries is just to much work for not much benefit. that thing called "minimalism" has simply failed to be of a real usefulness (I am exagerating a bit, but the truth is not elsewhere). it's like saying "don't let us have a knife at home, in case a thief gets in". but then you're just frustrating yourself. real attackers come with their own tools. regards, mouss To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Protections on inetd (and /sbin/* /usr/sbin/* in general)
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 seems a prudent measure to simply not set execute permission by "other" on such programs during the install, giving the user a handy "Permission denied" message when such an attempt is made. Since these files don't run with any extra privileges (i.e., they're not setuid or setgid), nothing stops a user from uploading their own copy and running it. Your proposal doesn't actually improve security; it just annoys the attacker. Whether this is a good thing or a waste of time is a matter of opinion; personally, I'm in the latter boat (i.e., I see no reason to do this). Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Protections on inetd (and /sbin/* /usr/sbin/* in general)
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 listeners... walter -- Walter W. Hop [EMAIL PROTECTED] | +31 6 24290808 | NEW KEY: 0x84813998 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
