[CGI] hoe (un)secure is cgi?

[GiLuX]

ik heb een linux bakje met apache en nu wil iemand graag op mijn dat bakje een paar ancient perl cgi scripts runnen.

ik heb het even getest en dat cgi gedoe draait verder prima onder apache maar voordat ik hem los laat gaan met zijn cgi scripts zou ik graag toch even weten hoe vulnarable ik mijn server hiermee maak.

in php kan je bv van alles en nog wat instellen per virtual directory wat wel en niet mag.

kan dat ook voor cgi?

ik heb al wel gezogd maar kan eigenlijk niet meer vinden dan hoe je safe kan programeren om tegen te gaan dat visitors geen rare fratsen met je scripts uithalen maar wat te doen als de programmeur zelf rare dingen uit wil halen in zijn scripts?

[gorgi_19]

Volgens mij kan je dat toch in Apache instellen (rechten per virtual dir) en niet in PHP? Dit is alleen toch een module? En als je Apache kan instellen, dan kan je ook voor Perl de rechten instellen..

[GiLuX]

Op donderdag 04 juli 2002 14:26 schreef gorgi_19 het volgende:
Volgens mij kan je dat toch in Apache instellen (rechten per virtual dir) en niet in PHP? Dit is alleen toch een module? En als je Apache kan instellen, dan kan je ook voor Perl de rechten instellen..

je kan dat idd voor php ook in apache.conf instellen,
(bv:
php_admin_value open_basedir
safe_mode
)
echter dit is php specifiek en zover ik weet kan dit niet voor cgi?

[HGM]

Je kan per virtualhost evt aangeven of er CGI scripts gedraait mogen worden.
Maar als je Suexec gebruikt dan kan er verder vrij weinig misgaan, zolang de rest van de configuratie ok is.

[Verwijderd]

als je zorgt dat cgi niet onder root draait kunnen ze bijna nix uitvoeren.

wel is het mogenlijk om met cgi door heel je systeem heen te kijken, ipv alleen het virtuele gedeelte.

ik kan bijv. een java-servlet met een cgi-script uitvoeren, terwijl mijn hoster zegt dit helemaal niet te ondersteunen

[GiLuX]

Op donderdag 04 juli 2002 14:34 schreef HGM het volgende:
Je kan per virtualhost evt aangeven of er CGI scripts gedraait mogen worden.
Maar als je Suexec gebruikt dan kan er verder vrij weinig misgaan, zolang de rest van de configuratie ok is.

yo HGM: aargh.

ik ben nu dus al een uurtje of twee aan het klooien met suexec.

apache oppnieuw compiled met suexec en in de log file zie ik dat het werkt.

maar zodra ik een user in mijn virtual host toevoeg krijg ik een "Internal Server Error" in mijn browser en in mijn log: "Premature end of script headers"

de UID en GID zijn >= 100

can you help me plz?

(deze draad hoort eigenlijk in advanced server toestanden gok ik of mischien wel non win32 os)

[Glimi]

Op donderdag 04 juli 2002 17:13 schreef GiLuX het volgende:
yo HGM: aargh.

ik ben nu dus al een uurtje of twee aan het klooien met suexec.

apache oppnieuw compiled met suexec en in de log file zie ik dat het werkt.

maar zodra ik een user in mijn virtual host toevoeg krijg ik een "Internal Server Error" in mijn browser en in mijn log: "Premature end of script headers"

de UID en GID zijn >= 100

can you help me plz?

(deze draad hoort eigenlijk in advanced server toestanden gok ik of mischien wel non win32 os)

Boven de line "Premature end of script headers" staat meestal nog een melding in je apache log. In mijn geval is het eigenlijk altijd "cannot setuid perl", wat opgelost kan worden door suidperl de goede rechten te geven

[GiLuX]

ben er al uit,ik weet al waarom ik die fout krijg

althans,
hij zegt ook nog dat de file die geexecuted moet worden niet in de docroot staat en dat klopt idd om dat ik niet een general dir wil waar iedereen zijn cgi uit moet server (stel dat er later meerdere users met cgi aan de slag willen)

wat ik had gedaan bij de cofigure line was:
suexec-userdir=/pad/naar/users_cgibin_dir
maar dat moet gewoon zijn eigen virtual document root zijn,
dus in dit geval:

suexec-userdir=html

hoe kan ik er nou voor zorgen dat als een user hier zijn cgibin heeft:
/home/someuser/cgibin

dat cgi files vanuit die cgibin ge-suexed worden??

[GiLuX]

lekker is dat:

CGI scripts in user directories (as specified by the USERDIR_SUFFIX definition, set by the --suexec-userdir option) will be executed as the owning user if and only if
the script was requested using the ~username syntax, and
all of the ownership and permission requirements are met
If the ~username URL format is used but the permissions/ownerships aren't correct, the result will be a '500 Internal Server Error' page, not the script being executed by the server user as in a non-suexec environment

....
Q:
The single --suexec-docroot value is irksome. I have 50 virtual hosts with DocumentRoot values like /vhost1, /vhost2, and so on. The only way I can get suexec to work with these is to use --suexec-docroot=/, which hardly seems secure.
A:
This is unfortunately the way it is with the suexec that comes with Apache up through version 1.3.11. The value you specify for --suexec-docroot must be an ancestor of all of the non-~username documents that use it. This restriction may be lifted in a future version, but even then it would require settings specified at compile-time, such as with something like --suexec-docroot=/vhost1,/vhost2.

there you have it,
het kan dus niet.

jaja, tenzij je dit hebt:
http://www.bla.com/~gilux/cgibin/mycgifile.cgi

dus het werkt alleen als je het via een user alias aanroept

damn!
eerste keer dat ik iets met cgi moet doen en ik heb er nu al weer genoeg van.