THE ADVANCED COMPUTING SYSTEMS ASSOCIATION The following paper was originally published in the Proceedings of the USENIX Annual Technical Conference Monterey California USA June   SBOX Put CGI Script
880K - views

THE ADVANCED COMPUTING SYSTEMS ASSOCIATION The following paper was originally published in the Proceedings of the USENIX Annual Technical Conference Monterey California USA June SBOX Put CGI Script

Stein Cold Spring Harbor Laboratory 57513 1999 by The USENIX Association All Rights Reserved Rights to individual papers remain with the author or the authors employer Permission is granted for noncommercial reproduction of the work for educational

Download Pdf

THE ADVANCED COMPUTING SYSTEMS ASSOCIATION The following paper was originally published in the Proceedings of the USENIX Annual Technical Conference Monterey California USA June SBOX Put CGI Script




Download Pdf - The PPT/PDF document "THE ADVANCED COMPUTING SYSTEMS ASSOCIATI..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.



Presentation on theme: "THE ADVANCED COMPUTING SYSTEMS ASSOCIATION The following paper was originally published in the Proceedings of the USENIX Annual Technical Conference Monterey California USA June SBOX Put CGI Script"— Presentation transcript:


Page 1
THE ADVANCED COMPUTING SYSTEMS ASSOCIATION The following paper was originally published in the Proceedings of the USENIX Annual Technical Conference Monterey, California, USA, June 6-11, 1999 SBOX: Put CGI Scripts in a Box Lincoln D. Stein Cold Spring Harbor Laboratory  1999 by The USENIX Association All Rights Reserved Rights to individual papers remain with the author or the author's employer. Permission is granted for noncommercial reproduction of the work for educational or research purposes. This copyright notice must be included in the reproduced paper. USENIX

acknowledges all trademarks herein. For more information about the USENIX Association: Phone: 1 510 528 8649 FAX: 1 510 548 5738 Email: office@usenix.org WWW: http://www.usenix.org
Page 2
SBO X: Put CGI Scripts in Bo Lincoln D.Stein Cold Spring Harb or ab or atory Cold Spring Harb or, NY, 11724 lstein@cshl.org, h ttp://stein.cshl.org Abstract sb ox is CGI wrapp er script that allo ws eb sites to safely gran CGI authoring privileges to un trusted or naiv e authors. The script increases securit in sev eral ys. It hanges the pro cess privileges of CGI scripts to matc h their o wners,

prev en ting one script from in terfering with another's data les or op erations. It establishes con gurable ceilings on script resource usage, oiding in ten tional or unin ten tional denial of service attac ks. Most imp ortan tly sb ox can also b e used to run un trusted CGI scripts within chr ot() -ed directory thereb prev en ting CGI scripts from accessing sensitiv e p ortions of the le system. sb ox can be used and redistributed freely The complete pac age is ailable for do wn- load at http://stein.cshl.or g/WWW/softwar e/sb ox/ In troduction Common Gatew yIn terface (CGI) scripts ere

among the rst tec hniques for creating in teractiv eb pages and probably remain the most p opular [Stein97]. erhaps the main reason for the enduring p opularit of CGI scripts is their simplicit create dynamic eb page, eb author writes program that prin ts short HTTP header follo ed b the con ten ts of the desired eb page. The author then mo es the program in to sp ecially designated \CGI directory" on the W eb serv er host. When the program's URL is requested, its output is displa ed on the W eb page. CGI script can be written in an lan- guage, compiled or in terpreted. A fully func- tional

CGI script can b e written in just three lines of Bourne shell scripting co de (including the #! line): #!/bin/sh echo -e "Content-type: text/plain\n" echo "Hello world!" The full CGI proto col [Coar pro vides mec hanisms for scripts to accept input from eb forms, get information ab out the curren op eration of the serv er, learn the name and IP address of the remote bro wser, and pass bac status information to the eb serv er. Comm unication b et een script and serv er is accomplished via en vironmen ariables and standard input/output. Essen tially , the CGI proto col is a transien t coshell

system [F wler in whic htheW eb serv er delegates the resp on- sibilit y of pro ducing the page con ten ton to an external program, the script. 1.1 Securit Problems with CGI Scripts The simplicit and ease with whic CGI scripts can be created is also the proto col's Ac hille's heel [Gar nkle, Rubin , Stein98a ]. It is so simple to write CGI scripts that programming no vices who ha no prior exp erience in net ork serv er soft are dev el- opmen can readily create in teractiv eb pages. And here's where the problem lies. No vices, and sometimes ev en exp erienced programmers, are prone to errors

that exp ose the eb serv er host to attac unscrupulous individuals. As an example of the problems b eginners run in to, consider the follo wing CGI script written in erl. Its in ten is to reco er an e-mail address from a submitted ll-out form
Page 3
and then mail a message to that address using the mail program. #!/usr/local/bin/perl use CGI qw(:standard); $mailto param('mailto'); $subject param('subject'); $contents param('contents'); open (MAIL,"|mail -s $subject $mailto"); print MAIL $contents"; print MAIL ".\n"; close MAIL; print "Content-type: text/plain\n\n" print "Mail sent to

$address."; This script, whic is in tended to be ypical of b eginner's program rather than illustrativ of good st yle, b egins using the ar am() function of the erl CGI mo dule [Stein98b to reco er the con ten ts of three HTML form elds named \mailto," \sub ject," and \con ten ts." The alues of \mailto" and \sub ject" are used to op en up a pip e to the Unix mail command. The v alue of \con ten ts" is then prin ted to the mail pro cess, whic h is then closed. The script ends yprin ting out a short con rmation message. This script has a n um ber of problems, in- cluding a reliance on the P TH

en vironmen ariable to resolv e the mail command, a fail- ure to examine the \con ten ts" eld for a line b eginning with a dot, whic hw ould terminate the mail message prematurely and failure to c hec k for errors after the op en and close() calls. Ho ev er the most egregious a is in the call to op en() whre the programmer passes the con ten ts of \sub ject" and \mail" to the shell without ha ving rst c hec ed them for metac haracters. Consider what happ ens when the wiley hac er pro vides the follo wing text as the v alue of the \mailto" eld: hackers_r_us@hackers.com The pip ed op en()

transforms this in to the follo wing call: mail hackers_r_us@hackers.com with the result that the system passw ord le is inadv erten tly mailed out to a p oten tial attac er. Other common problems in CGI scripts include the failure to hec the length of strings b efore cop ying them in to static bu ers, failure to hec for the existence of temp orary les b efore clobb ering them, and the failure to c hec k user-pro vided pathnames for the \.." haracters b efore op ening les. ossible CGI script exploits include a v ariet of denial of service attac ks. or example, CGI script that reads user-pro

vided input and sp o ols it to a disk le is vulnerable to the misc hievious hac er who uses a W eb rob ot to transmit an endless stream of random bits to the script. Ev en tually the serv er's le system will ll up, causing the host system to stall. Exp erience has sho wn that CGI scripts are ma jor source of vulnerabilit yonthe eb. Ov er the past v ears, dozens ell-kno wn and widely distributed CGI scripts ha b een found to con tain exploitable securit holes [Stein98c CER ]. Ev en exp erienced dev elop ers get burned from time to time. O enders include freew are/public domain scripts, suc has

ount.c gi as w ell as commer- cial pro ducts from suc h resp ected dev elop ers as Microsoft and Silicon Graphics. Under- standably most ebmasters are extremely cautious ab out installing new and un tested CGI scripts on their serv ers. One to limit the harm that p o orly- written CGI scripts can do is to run the eb serv er with as few privileges as p ossible. Most W eb serv ers run as an unprivileged user without login privileges, suc as \nob o dy ." CGI script pro cesses spa wned the serv er will ordinarily run under the same privileges as their paren t, and carefully con trolling le and

directory p ermissions, the ebmas- ter can limit the scop e of an y p oten tial dam- age that erran t CGI scripts can in ict on the serv er host. o increase safet yev en further, the W ebmaster could place the en tire serv er in to restricted directory using the hroot command. No an CGI scripts it spa wns will b e limited to the p ortion of the le sys- tem that the serv er runs in. 1.2 User-Main tained CGI Scripts No consider eb serv er run in an academic en vironmen or an In ternet service pro vider (ISP). Suc system gen-
Page 4
erally supp orts ultiple eb authors of arying lev els

of exp erience and aptitude. In an academic en vironmen t, the authors are studen ts, facult ymem b ers, and supp ort sta who are gran ted p ersonal W eb pages. In the case of an ISP ,the users are customers who ha e paid for W eb space, and can range from individuals who main tain p ersonal \v anit y" pages to large co-hosted corp orations. If users are allo ed to write and install their wn CGI scripts, then the risk from user- main tained scripts is magni ed sev eral fold. First of all, malicious author migh seek to break in to the eb serv er host writing CGI script that delib erately prob

es the host for holes. In man eb hosting en vironmen ts, authors are not giv en login shell. Instead they are constrained to uploading new and mo di ed HTML pages via FTP or eb publishing pac age suc as ron tP age [Microsoft ]. If authors are allo ed to upload erl scripts and compiled binaries for use as CGI scripts, this p olicy is easily circum en ted. Second, ev en if the host is protected running the eb serv er as an unprivileged user and in a c hange-ro ot directory , there is nothing to protect authors from eac h others' CGI scripts. Because all CGI scripts run under the same user accoun

and execute in the same hange-ro ot directory there is nothing protecting one author's data from another author's script. studen could write CGI script to p eek at the answ ers to a facult y mem b er's online quiz, kill other studen ts' CGI pro cesses, or ll user's guestb o ok le with obscene messages. In an ISP en vironmen t, one corp orate customer could write CGI script to sp on another customer's order en try system and clien database. Third, ev en if there is no activ in ten to do evil on the part of an author, single p o orly-written CGI script can still b e used b In ternet in truders

to compromise the securit of all authors on the system. or example, a guestbook script that do esn't hec for the presence of \.." directories in the path to its data le can easily be exploited to view or erwrite les main tained b y other authors. ourth, user-main tained CGI scripts are an in vitation to denial of service (DoS) attac ks. malicious script writer can launc DoS attac on the eb serv er host with erl script lik e the one sho wn b elo w, whic h forks itself forev er un til the serv er host runs out of slots in its pro cess table. It is p ossible that the system administrator will be

unable to log in to kill the runa y pro cess and ma ybe forced to reb o ot the mac hine: #!/usr/local/bin/perl fork() while 1; Finally it is dicult to trace an attac from a user-main tained CGI script bac ktoits wner. Since all scripts execute with the iden- tit y and privileges of the W eb serv er, there is no easy w y to determine whose script is, for example, lea ving 40 megab yte scratc h les in /tmp 1.3 rappers There are um ber of approac hes to the problem of user-main tained CGI scripts. One approac histooutla w them completely The site's administrators can preinstall um b er of

standard CGI scripts for users to link to and con gure the serv er so that no additional scripts can be added. Another solution is to submit all user-written scripts to an exacting co de review. Neither of these approac hes is particularly app ealing. The rst solution is unlik ely to b e p opular in the comp etitiv eW eb hosting mar- et where customers migrate to the service that o ers the most features for the least cost. The second solution is only practical for sites that ha eun usually generous administrativ resources or an un usually small um ber of users who w an t to install custom CGI

scripts. more practical solution is to use wr app er script. Instead of in oking user- main tained CGI scripts directly the eb serv er runs then indirectly via a wrapp er pro- gram. The wrapp er mo di es the en vironmen in some w y that mak ethe execution of the user-main tained script safer. The wrapp er is also good place to enforce securit p olicy decisions. or example, the wrapp er can k eep a log of the scripts it has run and can refuse to run scripts whose p ermissions are insecure.
Page 5
The rst and still most widely-used wrap- p er program w as giwr ap , written b y Nathan

Neulinger [Neulinger]. giwr ap p erforms sev eral useful functions. Its main feature is that it uses the Unix setuid() call to run user-main tained CGI scripts under the user and group ID of the script's wner rather than the shared eb serv er accoun t. This prev en ts one user's scripts from writing to data les main tained b y another, and mak es it easier to trac do wn problems caused p o orly written scripts. giwr ap also allo ws the ebmaster to place resource limitations on user-main tained scripts using the Berk eley setrlimit() call. This prev en ts um ber of delib erate and inadv erten t

DoS attac ks. The giwr ap program is straigh tforw ard to use. Once giwr ap is installed in the system CGI directory URLs used to in ok user-main tained scripts lik e this one: http://www.site.c om/~fr d/guestb ok.c gi are replaced b y URLs that in ok giwr ap http://www.site.c om/c gi-bin/c giwr ap/fr d/ guestb ok.c gi More recen tly the p opular Apac he eb serv er has shipp ed with built-in wrapp er program called suEXEC [Apac he Group]. The op eration of suEXEC is similar to giwr ap but it is more tigh tly in tegrated in to the eb serv er, making it unecessary to hange an URLs in order to

use it. In addition to hanging its user ID to matc that of the wner of the script, suEXEC logs eac script it executes along with the user and group ID that it runs under. It also p erforms series of consistency hec ks in order to detect unsafe practices. or example, suEXEC will refuse to run a script that is orld writable or whic is con tained within a w orld writable directory The main limitation of b oth giwr ap and suEXEC is that neither truly insulates scripts written b y one user from those written b yan- other. Naiv e users who store con den tial in- formation in w orld readable les and

directo- ries can still b e attac ed when another user's CGI script is used to peek at that data. In fact, although these scripts increase the se- curit yoftheW eb hosting service as a whole, they decrease the securit of the individual user. Because the wrapp ed script runs with the same privileges as the user, it has free ac- cess to all the user's les. poorly written script can b e tric ed in to c hanging the user's HTML do cumen ts or recursiv ely deleting his home directory It can also imp ersonate the user, for example b y sending e-mail from the user's accoun t. The sb ox rapper The sb

ox program is CGI wrapp er that go es b ey ond giwr ap and suEXEC to o er the follo wing features: 1. sb ox calls suid() to run the requested script with the privileges of the o wner of the script or the script's con taining di- rectory 2. It calls sgid() to run the requested script under the privileges of the group that wns the script or the script's con tain- ing directory 3. It performs consistency hec ks on the script le and directory wnerships to catc insecure situations suc as w orld- writable scripts. 4. It establishes limits on the script's use of CPU, memory , pro cesses, les and

other resources. 5. It calls chr ot() to run the target CGI script in restricted hange-ro ot direc- tory lo catated within the user's home di- rectory 6. It cleanses the en vironmen of informa- tion that is not germaine to CGI scripts. 7. It logs its actions and executes the target script. These features can be used together, or can be switc hed on and o selectiv ely to implemen tav ariet yof securit y p olicies. Once installed, sb ox is straigh tforw ard to use. o run an un trusted CGI script, create comp osite URL consisting of the path to sb ox follo ed the path to the target CGI script.

ypical URL for in oking
Page 6
user-supp orted script lo oks lik e this: http://www.site.c om/c gi-bin/sb ox/~fr d/ guestb ok.c gi sb ox can also b e used in conjunction with the virtual hosts feature pro vided b yApac he and other serv ers. With some serv ers, it is ev en p ossible to mak sb ox transparen t, so that its name do esn't app ear in the path. Asc heme to do this using the Apac he mo ewrite mo dule is presen ted later in this pap er. The next sections describ e eac of sb ox 's features in more detail and sho ws ho they can be used to increase the securit of the eb site.

2.1 suid()/sgid() eatures Before sb ox launc hes user-supp orted CGI script, it can be con gured to hange its UID and/or GID to matc the script's wner. There are p ossible arian ts of this feature. In the rst arian t, sb ox uses the script le to determine whic user and group to run as. This functionalit is similar to the sc heme implemen ted giwr ap In the second arian t, the wn- ership of the script is ignored; instead the o wnership of the directory that con tains it is used to determine the user and/or group. Allo wing sb ox to tak on the iden tit of the enclosing directory migh seem bit

obscure, but the rationale is that it giv es the ebmaster more exibilit than just using the script o wnership do es. or example, the ebmaster could use this tec hnique to create common gi-bin directory for use particular group of dev elop ers. The directory ould be wned pseudo-user and be group writable eac of the dev elop ers, allo wing an user in the group to create and edit CGI scripts. When the script runs, it executes under the p ermissions of the common pseudo-user accoun t, prev en ting it from mo difying an of the author's les or databases unless he explicitly giv es it p ermis- sion

to do so b y setting the group writable bit. Another strategy that the ebmaster migh an to adopt is to con gure sb ox so that it performs an sgid() only This will cause the target script to be executed with the group p ermissions of the script or enclos- ing directory but with the user p ermissions of the eb serv er. By adopting system- wide user-priv ate group strategy in whic eac h user is assigned a unique primary group, the script's author can exactly con trol what resources the script do es and do es not ha access to. This strategy also mak es it p ossi- ble to create scripts that cannot

mo dify their wn source co de le or binary risk b oth giwr ap and suEXEC are sub ject to. 2.2 Consistency Chec ks When sb ox launc hes, it c hec ks its en viron- men for signs that it has b een tamp ered with or that it is being run in an unsafe fashion. If an yofthe c hec ks fail, sb ox ab orts with an error message. The follo wing c hec ks are p erformed: 1. sb ox hec ks that it as launc hed b y the unprivileged user and group that the eb serv er runs as, for example nobody and nogroup This c hec kis to a oid the p ossibilit y that some user or group is try- ing to exploit the script's

set-user-id fea- tures from the command line. 2. It c hec ks whether it w as launc hed b y the ro ot user, and ab orts if so. This is often asignthat theW eb serv er is miscon g- ured. 3. It hec ks the target CGI script for set- user-id and set-group-id bits and refuses to run if so. Un trusted users shouldn't be allo ed to write suid or sgid scripts. 4. It c hec ks that the target CGI script is ex- ecutable b y other, and ab orts if not, as- suming that the script's author had some reason for turning o the w orld execute bit. 5. It hec ks that neither the target CGI script nor its enclosing

directory is o wned y unprivileged user and group that the eb serv er runs as. If the target is o wned y this user, it's p ossible that it is a tro- jan horse created b y a le upload script. 6. It c hec ks that neither the target le nor its enclosing directory is w orld writable.
Page 7
7. If the chr ot() feature is activ e, it c hec ks that the target script is lo cated within the directory that will b ecome the new ro ot. This is a prerequisite for launc hing the script after the chr ot() call. 8. Lastly sb ox hec ks that the target and its enclosing directory are wned users and/or

groups in an appro ed range, usually high-n um bered IDs. This pre- en ts sb ox from b eing tric ed in to run- ning script as sp ecial user suc as bin These c hec ks, along with the en vironmen sanitization p erformed later in the launc pro cess, go long to ard prev en ting man of the lo opholes and con guration er- rors that are frequen tly exploited b yin trud- ers. 2.3 Resource Con trols After applying its consistency c hec ks, sb ox applies resource limitations to the curren pro cess using the BSD-deriv ed setrlimit() system call. Limits include the size of the CGI pro cess, its residen

(virtual) size, the um ber of le descriptors it can op en, the size of the largest single le it can create, and the n um b er of subpro cesses it can spa wn. sb ox uses both \hard" resource limits and \soft" ones. The soft limits, whic can be adjusted up ards the CGI script simply calling setrlimit() itself, are set at lo w, stringen alues default. The hard limits, whic once set cannot be in- creased during the lifetime of the pro cess, use more lib eral alues. or example, the maxim um le size that the user-supp orted CGI script has soft limit of 100K, and hard limit of megab ytes. These alues

can be adjusted at sb ox compile time. The exception to this rule is the hard ceiling on core dumps, whic is set to size zero. This prev en ts the user's CGI script from creating core les and closes arious exploits that mak use of core dumps to reco er con - den tial information or to o erwrite other les. The net result of this design is that user-supp orted CGI scripts will, default, be executed in an en vironmen with strict resource con trols. If CGI script requires more of particular resource than the soft limits pro vide, it can increase the resource up to the preset hard limit calling

setr- limit() itself. This design limits problems caused resource hogging scripts written ynaiv e users without unduly restricting the options of sophisticated users who need more resources than the soft limits allo w. In addition to setting resource limits, sb ox also nices its o wn pro cess to a priorit y of 10. This helps eep CGI scripts from becoming to o uc of drain on loaded system. Unlik setrlimit() alues, priorit lev el, once increased, can nev er b e decreased. The priorit lev el and the soft and hard limits on all system resources are set at sb ox compile time. The system

administrator can hange the default alues, or ho ose not to set a particular limit at all. 2.4 Changing the Root Directory The crux of sb ox securit yis its c hange-ro ot function. If con gured to do so, sb ox will use the chr ot() system call to hange its ro ot directory to some sub directory enclosing the target CGI script. When the target CGI script runs, it will be unable to access parts of the lesystem outside the new ro ot directory This closes a large n um b er of CGI exploits, including unauthorized access to the system passw ord le, the mo di cation of user's .rhosts les, the creation

of hard links to system les in /tmp , and man y more. It also pro vides to con trol exactly whic system binaries and other resources that user-main tained CGI scripts ha e access to. Administrator-con gurable options de- termine ho sb ox ho oses whic directory to mak the new ro ot. In order for the target CGI script to be executed, it ust liv within the sub directory selected for the new ro ot. Ho ev er, most CGI scripts will also need access to copies of system les suc as in terpreters and shared libraries in order to function correctly Because it is incon enien for the user to in termix his

CGI scripts with system les, these les are usually stored in directories parallel to the directory that con tains the target
Page 8
script. Another consideration is the user's \do cumen t ro ot", the directory that con tains his static HTML les. An um b er of p opular CGI scripts, including guestb o ok scripts and page coun ters, require access to the user's HTML pages. In order for these scripts to ork under the sb ox system, the user's do cumen ro ot, or p ortion of it at least, ust also be lo cated within the new ro ot directory The lo cations of the new ro ot directory and the

target CGI script itself are con trolled the con guration ariables OOT and CGI BIN resp ectiv ely Both ariables are pathnames relativ to the user's do cumen ro ot. At ypical con guration will use the fol- lo wing v alues: ROOT ".." CGI_BIN "../cgi-bin" This con guration tells sb ox to lo ok for the target CGI script inside directory named gi-bin on the same lev el as the user's do c- umen ro ot directory The new ro ot direc- tory will be the paren of b oth the gi-bin directory and the user's do cumen ro ot. see ho this orks in practice, consider eb site in whic user-supp orted directo- ries

are lo cated in /u/username/pub/h tm where \username" is substituted with the lo- gin name of the user. In Apac he, this setup could be accomplished using the con gura- tion directiv UserDirpub/h tml ypical listing for /u/username/pub migh lo ok lik the example sho wn in able 1. When sb ox starts up, it determines the user's do cumen ro ot lo oking at the Apac he settings, whic h rev eals the directory /u/fred/pub/html It applies the CGI BIN relativ e path, to giv /u/fred/pub/cgi- bi as the directory in whic to searc for the CGI executable, and then applies the OOT relativ path to giv

/u/fred/pub as the directory that will become the new ro ot. When sb ox mak es the chr ot() call, /u/fred/pub b ecomes the top of the direc- tory tree, creating a directory hierarc y with a structure similar to a Unix ro ot lesystem. Files and directories ab o pub ,whic hmigh include the user's priv ate les, are o limits. Adra wbac k to this sc heme is that it mak es the user's en tire do cumen t tree visible to his CGI scripts, whic h migh t not alw ys b e desir- able. Ho ev er a sligh t mo di cation impro es the sc heme b y making only a selected p ortion of the user's do cumen t tree

visible. In this im- pro ed sc heme, the W eb serv er is con gured so that the user's do cumen t tree is found, for example, in /u/username/pub lic html , and sb ox is con gured to c hange its ro ot to a di- rectory named sb ox that is completely outside the public html do cumen ttree: ROOT "../sbox" CGI_BIN "../sbox/cgi-bin" or this con guration to ork seamlessly the user's directory should be set up some- thing lik e this: ls-F/u/fred public html/ doc root public html/sbox/->../sbox/html/ link sbox/bin/ sbox/cgi-bin/ scripts sbox/etc/ sbox/lib/ sbox/html/ sbox/tmp/ ... The user's CGI scripts

will no execute within the restricted sb ox sub directory and ha no access, default, to the user's HTML do cumen t tree. Ho ev er the user can gran access to selected HTML do cumen ts placing them in to public html/sbox/ whic is connected via sym b olic link to sbox/html/ This allo ws CGI-accessible les to b e accessed directly with aURL lik this one: http://www.site.c om/~fr d/sb ox/index.html while sb ox- con trolled CGI scripts are ac- cessed with a URL lik e this one: http://www.site.c om/c gi-bin/sb ox/~fr d/ guestb ok and CGI scripts that need to read or ma- nipulate static HTML les are

passed the additional path information in URLs lik this one:
Page 9
ls/u/username/pub total 10 drwxr-xr-x fred users 1024 Oct 23 06:27 bin/ system binaries drwxr-xr-x fred users 1024 Oct 19 20:44 cgi-bin/ CGI scripts drwxr-xr-x fred users 1024 Oct 12 16:59 dev/ device special files drwxr-xr-x fred users 1024 Oct 19 17:57 etc/ configuration files drwxr-xr-x fred users 1024 Oct 22 19:14 html/ HTML document root drwxr-xr-x fred users 1024 Oct 19 20:35 lib/ shared libraries drwxr-xr-x fred users 1024 Oct 23 05:48 tmp/ temporary files able 1: ypical directory listing for a user-supp orted

W eb directory http://www.site.c om/c gi-bin/sb ox/~fr d/ guestb ok/html/index.html If the Apac he eb serv er is being used, these URLs can be simpli ed signi can tly with URL rewriting rules. An example of this is sho wn b elo w. 2.5 En vironmen Cleansing Before executing the target CGI script, sb ox sets up clean en vironmen to run the target in. Dep ending on ho the eb serv er as launc hed, there ma be residual information in the en vironmen that is not germaine to the CGI proto col or ma in fact divulge sensitiv information, suc as database authen tication information, or priv ate P TH

directories. sb ox lters the curren ten vironmen t, allo w- ing through only those en vironmen tv ariables that are sp eci ed the CGI/1.1 proto col, suc as REMOTE ADDR, or whic con tain elds from the incoming HTTP request header, suc as HTTP USER GENT. In addition, sb ox recognizes and p ermits a small um b er of common extensions to the CGI/1.1 proto col, suc as the DOCUMENT OOT and SER VER ADMIN v ariables. Other ariables are not automatically copied in to the target script's en vironmen t. In particular the TH en vironmen ari- able, b ecause of its history of exploitation is not passed

through. Instead TH is set up using constan \safe path" set at compile time. By default, the safe path is /bin:/usr/bin:/ usr /l oc al/ bi Because the target script will be running in hange-ro ot directory it is lik ely that only /bin will b e a ailable to the target script. When p ossible, sb ox adjusts path-related en vironmen tv ariables so that they correctly re ect the hange-ro oted lesystem seen the user's CGI scripts. Among the en vi- ronmen ariables that are adjusted are the DOCUMENT OOT v ariable, whic h should poin t to the top of the user's do cumen t tree and TH TRANSLA TED, whic

hpoin ts to the le passed to the user's CGI script as ad- ditional path information. 2.6 Logging Before passing con trol to the user's CGI script, sb ox logs its actions. It prin ts out timestamp, the name of the CGI script b eing executed, and the UID and GID of the pro cess that it will execute the script as. Diagnostic information is also logged when sb ox 's consistency c hec ks fail, or when an error o ccurs during the pro cessing or execution of the target CGI script. By default, sb ox sends its log en tries to standard error, whic on most eb serv ers b ecomes incorp orated in to the

shared serv er error log le. Ho ev er sb ox can instead be con gured to write en tries in to a priv ate log le. There's there's p erformance p enalt in k eeping a priv ate log le, since sb ox ust op en the le for app ending ev ery time it runs. The main rationale for ha ving a log en try for eac CGI script executed is that it pro- vides an audit trail in the case of a CGI-based attac k. The time of the attac k can b e corre- lated with the sb ox log, and p ossibly lead to the iden ti cation of the script that as ex- ploited. The sb ox log could also be used to monitor CGI script usage for

patterns sug- gestiv e of probing activit
Page 10
Practical Considerations Con guring the sb ox executable and preparing user-supp orted directories are the most tedious parts of using the sb ox system. In order to reduce dep endencies on the external en vironmen t, sb ox do es not use con guration le. Instead, all its op erational parameters are determined at compile time via a series of prepro cessor #define s. Ab out three dozen de nes are con tained in a single include le, sbox.h whic the system ad- ministrator ust edit before compiling the executable. ortunately , the v ast ma

jorit yof the de nes are b oilerplate alues whic will not need to b e c hanged b y most sites. Only ab out a half dozen are truly site-sp eci c. System administrators used to mo dern con guration scripts will probably be dis- app oin ted this primitiv con guration pro cess, ev en though it is simple and straigh t- forw ard. or this reason, GNU on gur st yle con guration script [F riesenhalm is curren tly in preparation. more onerous task is setting up user- supp orted directories so that their CGI scripts run correctly in hange-ro ot en vi- ronmen t. On most mo dern Unices, compiled programs

need one or more shared libraries in order to execute. Either the user's CGI scripts ust be compiled statically or the new ro ot directory ust con tain /lib sub directory (or the dialect's equiv alen t) con taining the shared libraries the user needs. Other system supp ort les ma needed as ell. CGI scripts that require ac- cess to the DNS system for hostname resolution will need an /etc sub direc- tory con taining resolv.conf Scripts that p erform time calculations ma need access to the compiled timezone le, /usr/lib/zoneinf o/l oc alt im Programs that need access to device sp ecial les, suc

as /dev/null and /dev/zero will need the appropriate les created with the mknod program. Scripts written in in terpreted languages suc hasP erl will require a /bin di- rectory con taining the in terpreter executable, and an supp ort les that the in terpreter needs, suc h as co de libraries. Clearly there are dra wbac ks to replicating a good c unk of the ro ot lesystem for eac user-supp orted w eb directory or one thing, the disk storage requiremen ts ma b ecome prohibitiv on system with man users. One solution is to limit the yp e of CGI scripts that users can write to particular dev elopmen

system, suc as erl. Then only those les needed to supp ort the erl in terpreter will ha to be copied in to the user's scripting directory Another solution to this problem is to use NFS to moun tatrimmed setof /lib /bin and /etc directories in eac user-supp orted directory Ev en after the chr ot() op eration, the con ten ts of these directories will con tin ue to remain a ailable to the user's CGI scripts. Although this tec hnique creates lot of moun poin ts, the erhead for un used NFS moun ts is minimal [Stern], and an automoun daemon can be further used to reduce the load [Crosb ]. Ho ev er

if this tec hnique is used, care ust be tak en not to moun directories that con tain sensitiv information, suc as an /etc directory that con tains liv passw ord le. This ould defeat the purp ose of the c hange-ro ot system. minor dra wbac to using sb ox is that it is not completely transparen to the user. Instead of writing natural-lo oking CGI URLs, users ha eto be trained to in terp ose /cgi-bin/sbox in fron of an URL that poin ts to CGI script. On Apac he serv ers, an elegan t solution to this problem is to use the mo ewrite URL rewriting mo dule to automatically add the /cgi-bin/sbox pre x

to users' CGI URLs. or example, one could use a mo ewrite URL rewrite rule to transform URLs of the form: /~fr d/c gi/guestb ok in to URLs of the form: /c gi-bin/sb ox/~fr d/guestb ok y adding these directiv es to Apac he's con g- uration le:
Page 11
RewriteEngine On RewriteRule ^/~(.+)/cgi/(.+) /cgi-bin/sbox/~$1/$2 [PT,NS] Neither the remote user nor the the script's author ev er sees the longer URL. The name transformation is completely transparen t. Asabon us, this rewrite expres- sion also correctly handles additional path information app ended to the end of the URL. In order to

p erform its suid() sgid() and chr ot() functions, sb ox ust run with sup e- ruser privileges. This means that, lik gi- wr ap and suEXEC it ust be installed set- user-id to ro ot. This fact should giv ean ycau- tious Unix system administrator pause. Ho w- ev er, sb ox consists of only 700 lines of C co de, all of whic harea ailable for public scrutin sb ox is careful to oid using static bu ers and string cop op erations that could cause bu er o er o w. It also c hec ks its en viron- men at startup time to con rm that it as in ok ed b y the w eb serv er and not some other lo cal user.

Conclusions The sb ox wrapp er increases the securit yof eb sites that need to run un trusted CGI scripts. It prev en ts di eren users' CGI scripts from in terfering with eac other running eac user's program under distinct user and group IDs. It prev en ts user- main tained scripts from accessing sensitiv parts of the le system running eac script in hange-ro ot directory It lessens the impact of denial of service attac ks establishing p er-pro cess resource limits, and it oids certain common miscon gurations yc hec king the en vironmen t for consistency before it launc hes the target CGI

script. Lastly it creates an audit trail that can be used to trac do wn malicious or p o orly implemen ted CGI scripts. sb ox is not a panacea for CGI w o es. There are ariet of CGI-based attac ks that sb ox cannot prev en t. Chief among these are net ork-based attac ks. or example, if a CGI script can be tric ed in to probing rew all system from within the protected net ork, there is nothing that sb ox can do to prev en this yp e of attac k. completely insulate the user's en vironmen t from that of the host, ou need to step out of the Unix domain and use partitioned op erating system, suc as

Hewlett P ac kw ard's VirtualV ault tec hnology [Hewlett P ac ard ]. Finally it is imp ortan to remem ber that the sb ox wrapp er alone w on't mak eaW eb site secure. CGI script precautions are just one comp onen t of a carefully considered site secu- rit y p olicy that includes atten tion to op erat- ing system securit ,w eb serv er con guration, op erating and bac kup pro cedures, and user education. While nothing is ev er going to completely eliminate the risk of running un- trusted CGI scripts on a W eb serv er, the sb ox wrapp er do es go a long w yto ards limiting the p oten tial damage

that p o orly-written or malicious scripts can in ict. Ac kno wledgmen ts Man y thanks to Nathan Neulinger for the original giwr ap program whic h inspired this ork. also wish to thank the mem b ers of the Apac he Pro ject, whose eb serv er has pro en that op en source pro jects can pro vide the same p o er and stabilit yascon en tional pro ducts { if not more so. Av ailabilit sb ox is written in ANSI C and compiles on ultiple a ors of Unix. It can b e used and redistributed freely The complete pac age is ailable for do wnload at http://stein.cshl.or g/WWW/softwar e/sb ox/ References [Apac he

Group] The Apac he Group (1998). Ap ache suEXEC Supp ort http://www. ap ache.or g/do cs/suexe c.html [Coar] Coar and Robinson (1998). The WWW Common Gateway In- terfac e, ersion 1.1 In ternet Draft. ftp://ftp.ietf.or g/internet-dr afts/ dr aft-c ar-c gi-v11-00.txt
Page 12
[CER T] Computer Emergency Re- sp onse eam (CER T) (1996-1998). Multiple CGI-related advisories. ftp://ftp.c ert.or g/pub/c ert_advisories/ [Crosb y] Crosb (1997). AMD u- toMount Daemon The Lin ux Journal 35, Marc h 1997. http://www.ssc.c om/LJ/ issue35/amd.html [F wler] wler G. (1993). The Shel l as Servic Usenix

Summer 1993 ec hnical Conference Pro- ceedings, Cincinnati, Ohio. http: //www.usenix.or g/public ations/libr ary [F riesenhalm] riesenhalm (1997). uto- onf Makes for Portable Softwar .Byte, No em b er 1997. [Hewlett P ac ard] Hewlett ac ard Inc. (1998). HP Internet Se curity Virtual- ault Home Page http://www.hp.c om/ se curity/pr ducts/virtualvault/ [Gar nkle] Gar nkle with Spa ord (1997). Web Se curity Commer e. O'Reilly & Asso ciates, Sebastop ol CA. [Microsoft] Microsoft Corp oration (1998). ron tP age 98 Ov erview. http://www.micr osoft.c om/pr ducts/ pr dr ef/571_ov.htm [Neulinger]

Neulinger (1996-1998). gi- wr ap. ttp://www.umr.edu/~cgiwrap/ [R ubin] ubin A, Ge er D, and anum (1997). eb Securit y Sourceb o ok .John Wiley & Sons, New Y ork. [Stein97] Stein L, Ho w to Set Up and Main- tain a W eb Site , Chapters 8-9. A ddison- Wesley L ongman, Boston. [Stein98a] Stein (1998). eb Securit y: Step-b y-Step Reference Guide. ddison Wesley L ongman, Boston. [Stein98b] Stein L (1998). The Ocal Guide to Programming with CGI.pm. John Wiley & Sons, New Y ork. [Stein98c] Stein L (1998). The W eb Securit Q. ttp://www.w3.org/Securit y/F aq [Stern] Stern (1991). Managing NFS and NIS

O'R eil ly Asso ciates, Seb astop ol, CA.
Page 13
SBO X: Put CGI Scripts in Bo Lincoln D.Stein Cold Spring Harb or ab or atory Cold Spring Harb or, NY, 11724 lstein@cshl.org, h ttp://stein.cshl.org Abstract sb ox is CGI wrapp er script that allo ws eb sites to safely gran CGI authoring privileges to un trusted or naiv e authors. The script increases securit in sev eral ys. It hanges the pro cess privileges of CGI scripts to matc h their o wners, prev en ting one script from in terfering with another's data les or op erations. It establishes con gurable ceilings on script resource

usage, oiding in ten tional or unin ten tional denial of service attac ks. Most imp ortan tly sb ox can also b e used to run un trusted CGI scripts within chr ot() -ed directory thereb prev en ting CGI scripts from accessing sensitiv e p ortions of the le system. sb ox can be used and redistributed freely The complete pac age is ailable for do wn- load at http://stein.cshl.or g/WWW/softwar e/sb ox/ In troduction Common Gatew yIn terface (CGI) scripts ere among the rst tec hniques for creating in teractiv eb pages and probably remain the most p opular [Stein97]. erhaps the main reason for the

enduring p opularit of CGI scripts is their simplicit create dynamic eb page, eb author writes program that prin ts short HTTP header follo ed b the con ten ts of the desired eb page. The author then mo es the program in to sp ecially designated \CGI directory" on the W eb serv er host. When the program's URL is requested, its output is displa ed on the W eb page. CGI script can be written in an lan- guage, compiled or in terpreted. A fully func- tional CGI script can b e written in just three lines of Bourne shell scripting co de (including the #! line): #!/bin/sh echo -e "Content-type:

text/plain\n" echo "Hello world!" The full CGI proto col [Coar pro vides mec hanisms for scripts to accept input from eb forms, get information ab out the curren op eration of the serv er, learn the name and IP address of the remote bro wser, and pass bac status information to the eb serv er. Comm unication b et een script and serv er is accomplished via en vironmen ariables and standard input/output. Essen tially , the CGI proto col is a transien t coshell system [F wler in whic htheW eb serv er delegates the resp on- sibilit y of pro ducing the page con ten ton to an external program, the

script. 1.1 Securit Problems with CGI Scripts The simplicit and ease with whic CGI scripts can be created is also the proto col's Ac hille's heel [Gar nkle, Rubin , Stein98a ]. It is so simple to write CGI scripts that programming no vices who ha no prior exp erience in net ork serv er soft are dev el- opmen can readily create in teractiv eb pages. And here's where the problem lies. No vices, and sometimes ev en exp erienced programmers, are prone to errors that exp ose the eb serv er host to attac unscrupulous individuals. As an example of the problems b eginners run in to, consider the follo

wing CGI script written in erl. Its in ten is to reco er an e-mail address from a submitted ll-out form
Page 14
and then mail a message to that address using the mail program. #!/usr/local/bin/perl use CGI qw(:standard); $mailto param('mailto'); $subject param('subject'); $contents param('contents'); open (MAIL,"|mail -s $subject $mailto"); print MAIL $contents"; print MAIL ".\n"; close MAIL; print "Content-type: text/plain\n\n" print "Mail sent to $address."; This script, whic is in tended to be ypical of b eginner's program rather than illustrativ of good st yle, b egins using the

ar am() function of the erl CGI mo dule [Stein98b to reco er the con ten ts of three HTML form elds named \mailto," \sub ject," and \con ten ts." The alues of \mailto" and \sub ject" are used to op en up a pip e to the Unix mail command. The v alue of \con ten ts" is then prin ted to the mail pro cess, whic h is then closed. The script ends yprin ting out a short con rmation message. This script has a n um ber of problems, in- cluding a reliance on the P TH en vironmen ariable to resolv e the mail command, a fail- ure to examine the \con ten ts" eld for a line b eginning with a dot, whic hw

ould terminate the mail message prematurely and failure to c hec k for errors after the op en and close() calls. Ho ev er the most egregious a is in the call to op en() whre the programmer passes the con ten ts of \sub ject" and \mail" to the shell without ha ving rst c hec ed them for metac haracters. Consider what happ ens when the wiley hac er pro vides the follo wing text as the v alue of the \mailto" eld: hackers_r_us@hackers.com The pip ed op en() transforms this in to the follo wing call: mail hackers_r_us@hackers.com with the result that the system passw ord le is inadv erten tly

mailed out to a p oten tial attac er. Other common problems in CGI scripts include the failure to hec the length of strings b efore cop ying them in to static bu ers, failure to hec for the existence of temp orary les b efore clobb ering them, and the failure to c hec k user-pro vided pathnames for the \.." haracters b efore op ening les. ossible CGI script exploits include a v ariet of denial of service attac ks. or example, CGI script that reads user-pro vided input and sp o ols it to a disk le is vulnerable to the misc hievious hac er who uses a W eb rob ot to transmit an endless stream of

random bits to the script. Ev en tually the serv er's le system will ll up, causing the host system to stall. Exp erience has sho wn that CGI scripts are ma jor source of vulnerabilit yonthe eb. Ov er the past v ears, dozens ell-kno wn and widely distributed CGI scripts ha b een found to con tain exploitable securit holes [Stein98c CER ]. Ev en exp erienced dev elop ers get burned from time to time. O enders include freew are/public domain scripts, suc has ount.c gi as w ell as commer- cial pro ducts from suc h resp ected dev elop ers as Microsoft and Silicon Graphics. Under- standably most

ebmasters are extremely cautious ab out installing new and un tested CGI scripts on their serv ers. One to limit the harm that p o orly- written CGI scripts can do is to run the eb serv er with as few privileges as p ossible. Most W eb serv ers run as an unprivileged user without login privileges, suc as \nob o dy ." CGI script pro cesses spa wned the serv er will ordinarily run under the same privileges as their paren t, and carefully con trolling le and directory p ermissions, the ebmas- ter can limit the scop e of an y p oten tial dam- age that erran t CGI scripts can in ict on the serv er

host. o increase safet yev en further, the W ebmaster could place the en tire serv er in to restricted directory using the hroot command. No an CGI scripts it spa wns will b e limited to the p ortion of the le sys- tem that the serv er runs in. 1.2 User-Main tained CGI Scripts No consider eb serv er run in an academic en vironmen or an In ternet service pro vider (ISP). Suc system gen-
Page 15
erally supp orts ultiple eb authors of arying lev els of exp erience and aptitude. In an academic en vironmen t, the authors are studen ts, facult ymem b ers, and supp ort sta who are gran ted

p ersonal W eb pages. In the case of an ISP ,the users are customers who ha e paid for W eb space, and can range from individuals who main tain p ersonal \v anit y" pages to large co-hosted corp orations. If users are allo ed to write and install their wn CGI scripts, then the risk from user- main tained scripts is magni ed sev eral fold. First of all, malicious author migh seek to break in to the eb serv er host writing CGI script that delib erately prob es the host for holes. In man eb hosting en vironmen ts, authors are not giv en login shell. Instead they are constrained to uploading new

and mo di ed HTML pages via FTP or eb publishing pac age suc as ron tP age [Microsoft ]. If authors are allo ed to upload erl scripts and compiled binaries for use as CGI scripts, this p olicy is easily circum en ted. Second, ev en if the host is protected running the eb serv er as an unprivileged user and in a c hange-ro ot directory , there is nothing to protect authors from eac h others' CGI scripts. Because all CGI scripts run under the same user accoun and execute in the same hange-ro ot directory there is nothing protecting one author's data from another author's script. studen could

write CGI script to p eek at the answ ers to a facult y mem b er's online quiz, kill other studen ts' CGI pro cesses, or ll user's guestb o ok le with obscene messages. In an ISP en vironmen t, one corp orate customer could write CGI script to sp on another customer's order en try system and clien database. Third, ev en if there is no activ in ten to do evil on the part of an author, single p o orly-written CGI script can still b e used b In ternet in truders to compromise the securit of all authors on the system. or example, a guestbook script that do esn't hec for the presence of \.."

directories in the path to its data le can easily be exploited to view or erwrite les main tained b y other authors. ourth, user-main tained CGI scripts are an in vitation to denial of service (DoS) attac ks. malicious script writer can launc DoS attac on the eb serv er host with erl script lik e the one sho wn b elo w, whic h forks itself forev er un til the serv er host runs out of slots in its pro cess table. It is p ossible that the system administrator will be unable to log in to kill the runa y pro cess and ma ybe forced to reb o ot the mac hine: #!/usr/local/bin/perl fork() while 1;

Finally it is dicult to trace an attac from a user-main tained CGI script bac ktoits wner. Since all scripts execute with the iden- tit y and privileges of the W eb serv er, there is no easy w y to determine whose script is, for example, lea ving 40 megab yte scratc h les in /tmp 1.3 rappers There are um ber of approac hes to the problem of user-main tained CGI scripts. One approac histooutla w them completely The site's administrators can preinstall um b er of standard CGI scripts for users to link to and con gure the serv er so that no additional scripts can be added. Another solution is to

submit all user-written scripts to an exacting co de review. Neither of these approac hes is particularly app ealing. The rst solution is unlik ely to b e p opular in the comp etitiv eW eb hosting mar- et where customers migrate to the service that o ers the most features for the least cost. The second solution is only practical for sites that ha eun usually generous administrativ resources or an un usually small um ber of users who w an t to install custom CGI scripts. more practical solution is to use wr app er script. Instead of in oking user- main tained CGI scripts directly the eb serv er

runs then indirectly via a wrapp er pro- gram. The wrapp er mo di es the en vironmen in some w y that mak ethe execution of the user-main tained script safer. The wrapp er is also good place to enforce securit p olicy decisions. or example, the wrapp er can k eep a log of the scripts it has run and can refuse to run scripts whose p ermissions are insecure.
Page 16
The rst and still most widely-used wrap- p er program w as giwr ap , written b y Nathan Neulinger [Neulinger]. giwr ap p erforms sev eral useful functions. Its main feature is that it uses the Unix setuid() call to run

user-main tained CGI scripts under the user and group ID of the script's wner rather than the shared eb serv er accoun t. This prev en ts one user's scripts from writing to data les main tained b y another, and mak es it easier to trac do wn problems caused p o orly written scripts. giwr ap also allo ws the ebmaster to place resource limitations on user-main tained scripts using the Berk eley setrlimit() call. This prev en ts um ber of delib erate and inadv erten t DoS attac ks. The giwr ap program is straigh tforw ard to use. Once giwr ap is installed in the system CGI directory URLs used to

in ok user-main tained scripts lik e this one: http://www.site.c om/~fr d/guestb ok.c gi are replaced b y URLs that in ok giwr ap http://www.site.c om/c gi-bin/c giwr ap/fr d/ guestb ok.c gi More recen tly the p opular Apac he eb serv er has shipp ed with built-in wrapp er program called suEXEC [Apac he Group]. The op eration of suEXEC is similar to giwr ap but it is more tigh tly in tegrated in to the eb serv er, making it unecessary to hange an URLs in order to use it. In addition to hanging its user ID to matc that of the wner of the script, suEXEC logs eac script it executes along with the

user and group ID that it runs under. It also p erforms series of consistency hec ks in order to detect unsafe practices. or example, suEXEC will refuse to run a script that is orld writable or whic is con tained within a w orld writable directory The main limitation of b oth giwr ap and suEXEC is that neither truly insulates scripts written b y one user from those written b yan- other. Naiv e users who store con den tial in- formation in w orld readable les and directo- ries can still b e attac ed when another user's CGI script is used to peek at that data. In fact, although these scripts

increase the se- curit yoftheW eb hosting service as a whole, they decrease the securit of the individual user. Because the wrapp ed script runs with the same privileges as the user, it has free ac- cess to all the user's les. poorly written script can b e tric ed in to c hanging the user's HTML do cumen ts or recursiv ely deleting his home directory It can also imp ersonate the user, for example b y sending e-mail from the user's accoun t. The sb ox rapper The sb ox program is CGI wrapp er that go es b ey ond giwr ap and suEXEC to o er the follo wing features: 1. sb ox calls suid() to run the

requested script with the privileges of the o wner of the script or the script's con taining di- rectory 2. It calls sgid() to run the requested script under the privileges of the group that wns the script or the script's con tain- ing directory 3. It performs consistency hec ks on the script le and directory wnerships to catc insecure situations suc as w orld- writable scripts. 4. It establishes limits on the script's use of CPU, memory , pro cesses, les and other resources. 5. It calls chr ot() to run the target CGI script in restricted hange-ro ot direc- tory lo catated within the user's

home di- rectory 6. It cleanses the en vironmen of informa- tion that is not germaine to CGI scripts. 7. It logs its actions and executes the target script. These features can be used together, or can be switc hed on and o selectiv ely to implemen tav ariet yof securit y p olicies. Once installed, sb ox is straigh tforw ard to use. o run an un trusted CGI script, create comp osite URL consisting of the path to sb ox follo ed the path to the target CGI script. ypical URL for in oking
Page 17
user-supp orted script lo oks lik e this: http://www.site.c om/c gi-bin/sb ox/~fr d/ guestb

ok.c gi sb ox can also b e used in conjunction with the virtual hosts feature pro vided b yApac he and other serv ers. With some serv ers, it is ev en p ossible to mak sb ox transparen t, so that its name do esn't app ear in the path. Asc heme to do this using the Apac he mo ewrite mo dule is presen ted later in this pap er. The next sections describ e eac of sb ox 's features in more detail and sho ws ho they can be used to increase the securit of the eb site. 2.1 suid()/sgid() eatures Before sb ox launc hes user-supp orted CGI script, it can be con gured to hange its UID and/or GID to matc

the script's wner. There are p ossible arian ts of this feature. In the rst arian t, sb ox uses the script le to determine whic user and group to run as. This functionalit is similar to the sc heme implemen ted giwr ap In the second arian t, the wn- ership of the script is ignored; instead the o wnership of the directory that con tains it is used to determine the user and/or group. Allo wing sb ox to tak on the iden tit of the enclosing directory migh seem bit obscure, but the rationale is that it giv es the ebmaster more exibilit than just using the script o wnership do es. or example, the

ebmaster could use this tec hnique to create common gi-bin directory for use particular group of dev elop ers. The directory ould be wned pseudo-user and be group writable eac of the dev elop ers, allo wing an user in the group to create and edit CGI scripts. When the script runs, it executes under the p ermissions of the common pseudo-user accoun t, prev en ting it from mo difying an of the author's les or databases unless he explicitly giv es it p ermis- sion to do so b y setting the group writable bit. Another strategy that the ebmaster migh an to adopt is to con gure sb ox so that it

performs an sgid() only This will cause the target script to be executed with the group p ermissions of the script or enclos- ing directory but with the user p ermissions of the eb serv er. By adopting system- wide user-priv ate group strategy in whic eac h user is assigned a unique primary group, the script's author can exactly con trol what resources the script do es and do es not ha access to. This strategy also mak es it p ossi- ble to create scripts that cannot mo dify their wn source co de le or binary risk b oth giwr ap and suEXEC are sub ject to. 2.2 Consistency Chec ks When sb ox

launc hes, it c hec ks its en viron- men for signs that it has b een tamp ered with or that it is being run in an unsafe fashion. If an yofthe c hec ks fail, sb ox ab orts with an error message. The follo wing c hec ks are p erformed: 1. sb ox hec ks that it as launc hed b y the unprivileged user and group that the eb serv er runs as, for example nobody and nogroup This c hec kis to a oid the p ossibilit y that some user or group is try- ing to exploit the script's set-user-id fea- tures from the command line. 2. It c hec ks whether it w as launc hed b y the ro ot user, and ab orts if so. This

is often asignthat theW eb serv er is miscon g- ured. 3. It hec ks the target CGI script for set- user-id and set-group-id bits and refuses to run if so. Un trusted users shouldn't be allo ed to write suid or sgid scripts. 4. It c hec ks that the target CGI script is ex- ecutable b y other, and ab orts if not, as- suming that the script's author had some reason for turning o the w orld execute bit. 5. It hec ks that neither the target CGI script nor its enclosing directory is o wned y unprivileged user and group that the eb serv er runs as. If the target is o wned y this user, it's p ossible

that it is a tro- jan horse created b y a le upload script. 6. It c hec ks that neither the target le nor its enclosing directory is w orld writable.
Page 18
7. If the chr ot() feature is activ e, it c hec ks that the target script is lo cated within the directory that will b ecome the new ro ot. This is a prerequisite for launc hing the script after the chr ot() call. 8. Lastly sb ox hec ks that the target and its enclosing directory are wned users and/or groups in an appro ed range, usually high-n um bered IDs. This pre- en ts sb ox from b eing tric ed in to run- ning script as sp

ecial user suc as bin These c hec ks, along with the en vironmen sanitization p erformed later in the launc pro cess, go long to ard prev en ting man of the lo opholes and con guration er- rors that are frequen tly exploited b yin trud- ers. 2.3 Resource Con trols After applying its consistency c hec ks, sb ox applies resource limitations to the curren pro cess using the BSD-deriv ed setrlimit() system call. Limits include the size of the CGI pro cess, its residen (virtual) size, the um ber of le descriptors it can op en, the size of the largest single le it can create, and the n um b er of

subpro cesses it can spa wn. sb ox uses both \hard" resource limits and \soft" ones. The soft limits, whic can be adjusted up ards the CGI script simply calling setrlimit() itself, are set at lo w, stringen alues default. The hard limits, whic once set cannot be in- creased during the lifetime of the pro cess, use more lib eral alues. or example, the maxim um le size that the user-supp orted CGI script has soft limit of 100K, and hard limit of megab ytes. These alues can be adjusted at sb ox compile time. The exception to this rule is the hard ceiling on core dumps, whic is set to size zero.

This prev en ts the user's CGI script from creating core les and closes arious exploits that mak use of core dumps to reco er con - den tial information or to o erwrite other les. The net result of this design is that user-supp orted CGI scripts will, default, be executed in an en vironmen with strict resource con trols. If CGI script requires more of particular resource than the soft limits pro vide, it can increase the resource up to the preset hard limit calling setr- limit() itself. This design limits problems caused resource hogging scripts written ynaiv e users without unduly restricting

the options of sophisticated users who need more resources than the soft limits allo w. In addition to setting resource limits, sb ox also nices its o wn pro cess to a priorit y of 10. This helps eep CGI scripts from becoming to o uc of drain on loaded system. Unlik setrlimit() alues, priorit lev el, once increased, can nev er b e decreased. The priorit lev el and the soft and hard limits on all system resources are set at sb ox compile time. The system administrator can hange the default alues, or ho ose not to set a particular limit at all. 2.4 Changing the Root Directory The crux of sb ox

securit yis its c hange-ro ot function. If con gured to do so, sb ox will use the chr ot() system call to hange its ro ot directory to some sub directory enclosing the target CGI script. When the target CGI script runs, it will be unable to access parts of the lesystem outside the new ro ot directory This closes a large n um b er of CGI exploits, including unauthorized access to the system passw ord le, the mo di cation of user's .rhosts les, the creation of hard links to system les in /tmp , and man y more. It also pro vides to con trol exactly whic system binaries and other resources that

user-main tained CGI scripts ha e access to. Administrator-con gurable options de- termine ho sb ox ho oses whic directory to mak the new ro ot. In order for the target CGI script to be executed, it ust liv within the sub directory selected for the new ro ot. Ho ev er, most CGI scripts will also need access to copies of system les suc as in terpreters and shared libraries in order to function correctly Because it is incon enien for the user to in termix his CGI scripts with system les, these les are usually stored in directories parallel to the directory that con tains the target
Page

19
script. Another consideration is the user's \do cumen t ro ot", the directory that con tains his static HTML les. An um b er of p opular CGI scripts, including guestb o ok scripts and page coun ters, require access to the user's HTML pages. In order for these scripts to ork under the sb ox system, the user's do cumen ro ot, or p ortion of it at least, ust also be lo cated within the new ro ot directory The lo cations of the new ro ot directory and the target CGI script itself are con trolled the con guration ariables OOT and CGI BIN resp ectiv ely Both ariables are pathnames relativ to

the user's do cumen ro ot. At ypical con guration will use the fol- lo wing v alues: ROOT ".." CGI_BIN "../cgi-bin" This con guration tells sb ox to lo ok for the target CGI script inside directory named gi-bin on the same lev el as the user's do c- umen ro ot directory The new ro ot direc- tory will be the paren of b oth the gi-bin directory and the user's do cumen ro ot. see ho this orks in practice, consider eb site in whic user-supp orted directo- ries are lo cated in /u/username/pub/h tm where \username" is substituted with the lo- gin name of the user. In Apac he, this setup could be

accomplished using the con gura- tion directiv UserDirpub/h tml ypical listing for /u/username/pub migh lo ok lik the example sho wn in able 1. When sb ox starts up, it determines the user's do cumen ro ot lo oking at the Apac he settings, whic h rev eals the directory /u/fred/pub/html It applies the CGI BIN relativ e path, to giv /u/fred/pub/cgi- bi as the directory in whic to searc for the CGI executable, and then applies the OOT relativ path to giv /u/fred/pub as the directory that will become the new ro ot. When sb ox mak es the chr ot() call, /u/fred/pub b ecomes the top of the direc-

tory tree, creating a directory hierarc y with a structure similar to a Unix ro ot lesystem. Files and directories ab o pub ,whic hmigh include the user's priv ate les, are o limits. Adra wbac k to this sc heme is that it mak es the user's en tire do cumen t tree visible to his CGI scripts, whic h migh t not alw ys b e desir- able. Ho ev er a sligh t mo di cation impro es the sc heme b y making only a selected p ortion of the user's do cumen t tree visible. In this im- pro ed sc heme, the W eb serv er is con gured so that the user's do cumen t tree is found, for example, in /u/username/pub lic

html , and sb ox is con gured to c hange its ro ot to a di- rectory named sb ox that is completely outside the public html do cumen ttree: ROOT "../sbox" CGI_BIN "../sbox/cgi-bin" or this con guration to ork seamlessly the user's directory should be set up some- thing lik e this: ls-F/u/fred public html/ doc root public html/sbox/->../sbox/html/ link sbox/bin/ sbox/cgi-bin/ scripts sbox/etc/ sbox/lib/ sbox/html/ sbox/tmp/ ... The user's CGI scripts will no execute within the restricted sb ox sub directory and ha no access, default, to the user's HTML do cumen t tree. Ho ev er the user can gran

access to selected HTML do cumen ts placing them in to public html/sbox/ whic is connected via sym b olic link to sbox/html/ This allo ws CGI-accessible les to b e accessed directly with aURL lik this one: http://www.site.c om/~fr d/sb ox/index.html while sb ox- con trolled CGI scripts are ac- cessed with a URL lik e this one: http://www.site.c om/c gi-bin/sb ox/~fr d/ guestb ok and CGI scripts that need to read or ma- nipulate static HTML les are passed the additional path information in URLs lik this one:
Page 20
ls/u/username/pub total 10 drwxr-xr-x fred users 1024 Oct 23 06:27

bin/ system binaries drwxr-xr-x fred users 1024 Oct 19 20:44 cgi-bin/ CGI scripts drwxr-xr-x fred users 1024 Oct 12 16:59 dev/ device special files drwxr-xr-x fred users 1024 Oct 19 17:57 etc/ configuration files drwxr-xr-x fred users 1024 Oct 22 19:14 html/ HTML document root drwxr-xr-x fred users 1024 Oct 19 20:35 lib/ shared libraries drwxr-xr-x fred users 1024 Oct 23 05:48 tmp/ temporary files able 1: ypical directory listing for a user-supp orted W eb directory http://www.site.c om/c gi-bin/sb ox/~fr d/ guestb ok/html/index.html If the Apac he eb serv er is being used, these URLs can be

simpli ed signi can tly with URL rewriting rules. An example of this is sho wn b elo w. 2.5 En vironmen Cleansing Before executing the target CGI script, sb ox sets up clean en vironmen to run the target in. Dep ending on ho the eb serv er as launc hed, there ma be residual information in the en vironmen that is not germaine to the CGI proto col or ma in fact divulge sensitiv information, suc as database authen tication information, or priv ate P TH directories. sb ox lters the curren ten vironmen t, allo w- ing through only those en vironmen tv ariables that are sp eci ed the CGI/1.1 proto

col, suc as REMOTE ADDR, or whic con tain elds from the incoming HTTP request header, suc as HTTP USER GENT. In addition, sb ox recognizes and p ermits a small um b er of common extensions to the CGI/1.1 proto col, suc as the DOCUMENT OOT and SER VER ADMIN v ariables. Other ariables are not automatically copied in to the target script's en vironmen t. In particular the TH en vironmen ari- able, b ecause of its history of exploitation is not passed through. Instead TH is set up using constan \safe path" set at compile time. By default, the safe path is /bin:/usr/bin:/ usr /l oc al/ bi Because

the target script will be running in hange-ro ot directory it is lik ely that only /bin will b e a ailable to the target script. When p ossible, sb ox adjusts path-related en vironmen tv ariables so that they correctly re ect the hange-ro oted lesystem seen the user's CGI scripts. Among the en vi- ronmen ariables that are adjusted are the DOCUMENT OOT v ariable, whic h should poin t to the top of the user's do cumen t tree and TH TRANSLA TED, whic hpoin ts to the le passed to the user's CGI script as ad- ditional path information. 2.6 Logging Before passing con trol to the user's CGI script,

sb ox logs its actions. It prin ts out timestamp, the name of the CGI script b eing executed, and the UID and GID of the pro cess that it will execute the script as. Diagnostic information is also logged when sb ox 's consistency c hec ks fail, or when an error o ccurs during the pro cessing or execution of the target CGI script. By default, sb ox sends its log en tries to standard error, whic on most eb serv ers b ecomes incorp orated in to the shared serv er error log le. Ho ev er sb ox can instead be con gured to write en tries in to a priv ate log le. There's there's p erformance p enalt

in k eeping a priv ate log le, since sb ox ust op en the le for app ending ev ery time it runs. The main rationale for ha ving a log en try for eac CGI script executed is that it pro- vides an audit trail in the case of a CGI-based attac k. The time of the attac k can b e corre- lated with the sb ox log, and p ossibly lead to the iden ti cation of the script that as ex- ploited. The sb ox log could also be used to monitor CGI script usage for patterns sug- gestiv e of probing activit
Page 21
Practical Considerations Con guring the sb ox executable and preparing user-supp orted

directories are the most tedious parts of using the sb ox system. In order to reduce dep endencies on the external en vironmen t, sb ox do es not use con guration le. Instead, all its op erational parameters are determined at compile time via a series of prepro cessor #define s. Ab out three dozen de nes are con tained in a single include le, sbox.h whic the system ad- ministrator ust edit before compiling the executable. ortunately , the v ast ma jorit yof the de nes are b oilerplate alues whic will not need to b e c hanged b y most sites. Only ab out a half dozen are truly site-sp eci c.

System administrators used to mo dern con guration scripts will probably be dis- app oin ted this primitiv con guration pro cess, ev en though it is simple and straigh t- forw ard. or this reason, GNU on gur st yle con guration script [F riesenhalm is curren tly in preparation. more onerous task is setting up user- supp orted directories so that their CGI scripts run correctly in hange-ro ot en vi- ronmen t. On most mo dern Unices, compiled programs need one or more shared libraries in order to execute. Either the user's CGI scripts ust be compiled statically or the new ro ot directory ust con

tain /lib sub directory (or the dialect's equiv alen t) con taining the shared libraries the user needs. Other system supp ort les ma needed as ell. CGI scripts that require ac- cess to the DNS system for hostname resolution will need an /etc sub direc- tory con taining resolv.conf Scripts that p erform time calculations ma need access to the compiled timezone le, /usr/lib/zoneinf o/l oc alt im Programs that need access to device sp ecial les, suc as /dev/null and /dev/zero will need the appropriate les created with the mknod program. Scripts written in in terpreted languages suc hasP erl will

require a /bin di- rectory con taining the in terpreter executable, and an supp ort les that the in terpreter needs, suc h as co de libraries. Clearly there are dra wbac ks to replicating a good c unk of the ro ot lesystem for eac user-supp orted w eb directory or one thing, the disk storage requiremen ts ma b ecome prohibitiv on system with man users. One solution is to limit the yp e of CGI scripts that users can write to particular dev elopmen system, suc as erl. Then only those les needed to supp ort the erl in terpreter will ha to be copied in to the user's scripting directory Another

solution to this problem is to use NFS to moun tatrimmed setof /lib /bin and /etc directories in eac user-supp orted directory Ev en after the chr ot() op eration, the con ten ts of these directories will con tin ue to remain a ailable to the user's CGI scripts. Although this tec hnique creates lot of moun poin ts, the erhead for un used NFS moun ts is minimal [Stern], and an automoun daemon can be further used to reduce the load [Crosb ]. Ho ev er if this tec hnique is used, care ust be tak en not to moun directories that con tain sensitiv information, suc as an /etc directory that con tains

liv passw ord le. This ould defeat the purp ose of the c hange-ro ot system. minor dra wbac to using sb ox is that it is not completely transparen to the user. Instead of writing natural-lo oking CGI URLs, users ha eto be trained to in terp ose /cgi-bin/sbox in fron of an URL that poin ts to CGI script. On Apac he serv ers, an elegan t solution to this problem is to use the mo ewrite URL rewriting mo dule to automatically add the /cgi-bin/sbox pre x to users' CGI URLs. or example, one could use a mo ewrite URL rewrite rule to transform URLs of the form: /~fr d/c gi/guestb ok in to URLs of the

form: /c gi-bin/sb ox/~fr d/guestb ok y adding these directiv es to Apac he's con g- uration le:
Page 22
RewriteEngine On RewriteRule ^/~(.+)/cgi/(.+) /cgi-bin/sbox/~$1/$2 [PT,NS] Neither the remote user nor the the script's author ev er sees the longer URL. The name transformation is completely transparen t. Asabon us, this rewrite expres- sion also correctly handles additional path information app ended to the end of the URL. In order to p erform its suid() sgid() and chr ot() functions, sb ox ust run with sup e- ruser privileges. This means that, lik gi- wr ap and suEXEC it ust be

installed set- user-id to ro ot. This fact should giv ean ycau- tious Unix system administrator pause. Ho w- ev er, sb ox consists of only 700 lines of C co de, all of whic harea ailable for public scrutin sb ox is careful to oid using static bu ers and string cop op erations that could cause bu er o er o w. It also c hec ks its en viron- men at startup time to con rm that it as in ok ed b y the w eb serv er and not some other lo cal user. Conclusions The sb ox wrapp er increases the securit yof eb sites that need to run un trusted CGI scripts. It prev en ts di eren users' CGI scripts from in

terfering with eac other running eac user's program under distinct user and group IDs. It prev en ts user- main tained scripts from accessing sensitiv parts of the le system running eac script in hange-ro ot directory It lessens the impact of denial of service attac ks establishing p er-pro cess resource limits, and it oids certain common miscon gurations yc hec king the en vironmen t for consistency before it launc hes the target CGI script. Lastly it creates an audit trail that can be used to trac do wn malicious or p o orly implemen ted CGI scripts. sb ox is not a panacea for CGI w o es.

There are ariet of CGI-based attac ks that sb ox cannot prev en t. Chief among these are net ork-based attac ks. or example, if a CGI script can be tric ed in to probing rew all system from within the protected net ork, there is nothing that sb ox can do to prev en this yp e of attac k. completely insulate the user's en vironmen t from that of the host, ou need to step out of the Unix domain and use partitioned op erating system, suc as Hewlett P ac kw ard's VirtualV ault tec hnology [Hewlett P ac ard ]. Finally it is imp ortan to remem ber that the sb ox wrapp er alone w on't mak eaW eb site

secure. CGI script precautions are just one comp onen t of a carefully considered site secu- rit y p olicy that includes atten tion to op erat- ing system securit ,w eb serv er con guration, op erating and bac kup pro cedures, and user education. While nothing is ev er going to completely eliminate the risk of running un- trusted CGI scripts on a W eb serv er, the sb ox wrapp er do es go a long w yto ards limiting the p oten tial damage that p o orly-written or malicious scripts can in ict. Ac kno wledgmen ts Man y thanks to Nathan Neulinger for the original giwr ap program whic h inspired

this ork. also wish to thank the mem b ers of the Apac he Pro ject, whose eb serv er has pro en that op en source pro jects can pro vide the same p o er and stabilit yascon en tional pro ducts { if not more so. Av ailabilit sb ox is written in ANSI C and compiles on ultiple a ors of Unix. It can b e used and redistributed freely The complete pac age is ailable for do wnload at http://stein.cshl.or g/WWW/softwar e/sb ox/ References [Apac he Group] The Apac he Group (1998). Ap ache suEXEC Supp ort http://www. ap ache.or g/do cs/suexe c.html [Coar] Coar and Robinson (1998). The WWW Common Gateway

In- terfac e, ersion 1.1 In ternet Draft. ftp://ftp.ietf.or g/internet-dr afts/ dr aft-c ar-c gi-v11-00.txt
Page 23
[CER T] Computer Emergency Re- sp onse eam (CER T) (1996-1998). Multiple CGI-related advisories. ftp://ftp.c ert.or g/pub/c ert_advisories/ [Crosb y] Crosb (1997). AMD u- toMount Daemon The Lin ux Journal 35, Marc h 1997. http://www.ssc.c om/LJ/ issue35/amd.html [F wler] wler G. (1993). The Shel l as Servic Usenix Summer 1993 ec hnical Conference Pro- ceedings, Cincinnati, Ohio. http: //www.usenix.or g/public ations/libr ary [F riesenhalm] riesenhalm (1997). uto- onf

Makes for Portable Softwar .Byte, No em b er 1997. [Hewlett P ac ard] Hewlett ac ard Inc. (1998). HP Internet Se curity Virtual- ault Home Page http://www.hp.c om/ se curity/pr ducts/virtualvault/ [Gar nkle] Gar nkle with Spa ord (1997). Web Se curity Commer e. O'Reilly & Asso ciates, Sebastop ol CA. [Microsoft] Microsoft Corp oration (1998). ron tP age 98 Ov erview. http://www.micr osoft.c om/pr ducts/ pr dr ef/571_ov.htm [Neulinger] Neulinger (1996-1998). gi- wr ap. ttp://www.umr.edu/~cgiwrap/ [R ubin] ubin A, Ge er D, and anum (1997). eb Securit y Sourceb o ok .John Wiley & Sons, New Y ork.

[Stein97] Stein L, Ho w to Set Up and Main- tain a W eb Site , Chapters 8-9. A ddison- Wesley L ongman, Boston. [Stein98a] Stein (1998). eb Securit y: Step-b y-Step Reference Guide. ddison Wesley L ongman, Boston. [Stein98b] Stein L (1998). The Ocal Guide to Programming with CGI.pm. John Wiley & Sons, New Y ork. [Stein98c] Stein L (1998). The W eb Securit Q. ttp://www.w3.org/Securit y/F aq [Stern] Stern (1991). Managing NFS and NIS O'R eil ly Asso ciates, Seb astop ol, CA.