Indledning

Oprindeligt, vi kun havde en shell på UNIX. Når kørte en kommando, skroget vil forsøge at påberåbe sig en af de exec () system opfordrer det. Det kommandoen var en eksekverbar, den exec ville lykkes, og kommandoen ville køre. Hvis exec () mislykkedes, råtanken ikke ville give op, i stedet ville det forsøge at fortolke kommando fil som om det var en shell script. Det fungerer fint, så længe der kun er en shell på systemet. Men hvad nu, hvis du bruger en shell som din interaktive og ønsker at køre et script skrevet i en anden shell's sprog?

Dette er hvor #! trick kommer ind tanken om at bruge # til at repræsentere en kommentar stammede med CSH og blev hurtigt tilføjet til Bourne shell. Nu alle råtanke ved at ignorere ting efter en #. Så vi kan tilføje en ledende linje noget lignende "#! / Usr / bin / ksh". Til yderklædningen denne linje er blot en kommentar. Men hvis kerne forsøger at udføre en fil med denne linje, vil det exec den specificerede tolk og videregive scriptet til det. Så shell scripts bliver eksekverbare temmelig meget gerne reelle eksekverbare filer er. Nu når et skuffeselskab forsøger at exec en shell script, det lykkes.

Hvad nu, hvis du lader off the #! line? Nå, kernen exec vil mislykkes. Deres gennemsnitlige skallen vil derefter forsøge at køre scriptet selv. Et par skaller vil forsøge at inspicere script til at prøve at gætte sproget. Dette er ikke godt. Du kan køre ksh som din interaktive shell og skrivning ksh scripts. Hvis du senere skifte til bash som et interaktivt skallen, nogle af dine scripts kan fortsætte med at køre, mens andre måske ikke. Også linjen er en kommentar , som giver en vigtig nøgle til en programmør, der ser på script til at forstå det. Vide, hvilket sprog forfatteren forsøger at bruge, er en stor hjælp.

Selv om jeg har brugt udtrykket "Shell", der faktisk er denne teknik kan bruges sammen med mange programmer, der ikke skaller. Her er et "script" til at vise et multiline besked:

#! /usr/bin/cat
Line 1
Line 2 
Line 3

#! /usr/bin/sed 1d
Line 1
Line 2 
Line 3

#! /usr/local/bin/perl -w

#! /usr/local/bin/perl -w
print "script name is ", $0, "\n";
while (@ARGV) {
        $ARGV = shift @ARGV;
        print "argument ", $i++,  " is ", $ARGV, "\n";
}

system "ps -f -ww";

$ ./perlargs one two three
Name "main::i" used only once: possible typo at ./perlargs line 10.
script name is ./perlargs
argument 0 is one
argument 1 is two
argument 2 is three
                 UID        PID   PPID    STIME TTY     TIME CMD
                 perderabo   69      1 17:47:28 n01  0:00.24 /bin/ksh -l
                 perderabo  201     69 18:28:22 n01  0:00.03 /usr/local/bin/perl -w ./perlargs one two three
                 perderabo 2055    201 18:28:22 n01  0:00.01 ps -f -ww
$

Formatet for #! Line

Vi kan sige med sikkerhed, at de første 2 tegn skal være "#!". Eller kan vi? Mange systemer, synes det, er villige til at slette førende hvidt rum. Min anbefaling er at starte med #!. Det traditionelle.

Næste der kan være en valgfri plads. Nogle dokumentation siger dette rum er nødvendig, men så vidt man kan fastslå den eneste Unix frigivelse til at kræve, at rummet var et øjebliksbillede frigivelse af BSD 4.1 ... dette var ikke en generel frigivelse). Faktisk ser det ud til, at du kan have flere rum, hvis du vil. Og nogle test med tabulatortegn er blevet gjort, og synes at virke. Min anbefaling er at udsætte med nul eller ét rum.

Derefter kommer den fulde sti til tolk og ligesom alle fuld stier, det skal starte med en /. Ups, en anden undtagelse ... Linuxkernen (mindst version 2.0.34) er villig til at acceptere en relativ sti. Min anbefaling er ikke gør det.

Vi kan ske. Eller vi kan have valgfri hvidt rum, der fører til vores enkelt argument. Bortset fra, at nogle versioner af FreeBSD håndtere flere argumenter.

De fleste udgaver af BSD og HP-UX vil strimler efterfølgende hvidt rum. Andre versioner af Unix behandle efterfølgende blanke tegn som gyldige tegn. Og et par udgaver af BSD kan acceptere en efterfølgende kommentar afgrænset af en # karakter.

Hvor længe kan den linje være? Et par versioner af Unix indstille grænse så lav som 32 tegn. FreeBSD kan tilsyneladende håndterer 8192 tegn.

Mindst linjen altid slutter med Unix standard \ n karakter, right? Nå, ikke altid. Nogle versioner af Unix vil tolerere en \ r \ n slutter og bånd off the \ r mens andre ikke vil gøre det.

Dette er ikke som standard, som det kunne være ...

Argumentet 0 i processen, ikke Scriptet

Der er en anden måde at implementeringer kan variere. Overvej perl script, at jeg løb ar slutningen af del 1. Min råtanken har tilnærmelsesvis svarer til
execl ( ". / perlargs", ". / perlargs", "En", "to", "tre", (char *) NULL)
og kernen omdannes det til den omtrentlige svarende til
execl ( "/ usr / local / bin /perl", "/ usr / local / bin /perl", "-W", ". / Perlargs", "en", "to", "tre", (char *) NULL)

Fremhævet med rødt er argumentet nul som i konventionen er det samme som stien på det program blive henrettet. Et bemærkelsesværdigt udførelse er, at login-programmet vil indstille den til ting som "-ksh". Oprindeligt eksekverbare shell scripts havde argumentet 0 indstillet til navnet på det script i stedet for navnet på den tolk. Disse dage, navnet på den tolk er fælles. Det sidste hold-out jeg kender, er HP-UX, som beskriver argument 0 til navnet på det script.

Når eksekverbare shell scripts blev første gang indført de hædret den suid bit. Det var en katastrofe for sikkerhed. Overvej et script opkald / usr / sbin / katastrofe. Og vi gjorde:
chown root / usr / sbin / katastrofe
chmod 4755 / usr / sbin / katastrofe
Naturligvis /, / usr, / usr / sbin kun skrives ved roden. Og selve besvarelsen er bare:
#! / bin / sh
Det er rigtigt. Scriptet er en enkelt linje uden skjulte tegn. Råtanken vil ignorere det, fordi det er en kommentar og derefter forlade, fordi der ikke er andre linjer. Dette script er allerede usikre og er sårbare over for to forskellige angreb.

Angreb 1: link til-i

Hvis vi gør:
ln-s / usr / sbin / katastrofe. /-i
og sørge for at udføre vores nye symbolsk link kaldet "-i". Hvis vi udføre de egentlige / usr / sbin / katastrofe, vi gør, hvad der svarer til:
execl ( "/ bin / sh", "/ usr / sbin / katastrofe", "/ usr / sbin / katastrofe", (char *) NULL)
Intet problem der. Det er, hvad vi havde forventet. Men når vi løber kopi særlige link kaldet "-i" vi gør:
execl ( "/ bin / sh", "-i", "-i", (char *) NULL)
Dette forårsager suid shell til at opføre sig som en interaktiv shell! Skallen blev hurtigt ændret til at acceptere en enkelt bindestreg som afslutningen på skifte indstilling argumenter. Så vi ændrer vores én linje script at læse:
#! / bin / sh --
Nu samme trick ville medføre:
execl ( "/ bin / sh", "-i", "-", "-i", (char *) NULL)
Augument nul er stadig "-i", men det er harmløst. Det kan måske endda være nyttigt, fordi det gør dette angreb mere mærkbar med ps kommando.

Attack 2: at ændre link

Denne ene er sværere at forklare. Som før, gør vi et symbolsk link til scriptet under angreb, men denne gang navnet betyder ikke noget. Så vil vi køre scriptet via vores nye symbolske link. Så vi hurtigt ændre symbolsk link til at pege på et onde script. Vi ønsker at ændre, hvad den symbolske link peger på efter kerne åbner det, men før tolk åbner det. Dette er et kapløb betingelse og det vil ikke arbejde hver gang. Det kræver også en smule smart programmering for at trække denne en off. Men gjort korrekt, vil vi have vores onde script kører som root.

Suid Scripts Deaktiveret

Fordi det ikke var muligt at skrive en sikker suid shell script, begrebet suid shell scripts blev fjernet fra Unix. Omkring dette tidspunkt programmet sudo blev skrevet, og dette hovedsagelig oviated behovet for suid shell-scripts. Jeg tror ikke, at enhver version af unix udgivet i de sidste 15 år har disse problemer. (Og hvis jeg gjorde, ville jeg ikke har drøftet disse angreb. ) Nu håber jeg, du kan se, hvorfor mange gamle tid system admins (som mig) har stadig en mørk baggrund af suid shell-scripts.

Tilbagelevering af Suid Scripts

Solaris nu støtter suid shell-scripts, men det er immune over for disse angreb. Det sker ved at sikre, at scriptet er åbnet kun én gang i tilfælde af en suid script. Hvis suid bit er indstillet, Solaris bruger fd filsystem passere scriptet til tolk. Havde min perlargs script blevet suid på Solaris, ville det have været køre noget lignende:
execl ( "/ usr / local / bin /perl"," / Usr / local / bin /perl","-W "," / dev/fd/3 "," en "," to "," tre ", (char *) NULL)
og når perl åbnet / dev/fd/3, det bare bliver en anden åben fil descripter peger på den samme fil som uanset er åbnet som fd 3. Bemærk, at inde i script, der er ingen måde at få navnet bortset / dev/fd/3.

Fordi navnet anvendes, er skjult for de intrepreter, der ikke er nogen skade, hvis dette navn var noget mærkeligt gerne "-i". Fordi script er åbnet én gang, er der ingen skade, hvis et symbolsk link pludselig skiftede til et onde script.

Men bemærk, at dette i sidste ende får os til et stadium, hvor en en linje script, der kun indeholder en kommentar kan sikkert køre. Der kan stadig være andre sikkerhedsmæssige problemer med en dårligt skrevet suid script. Hvis du skal bruge suid shell-scripts, er der her et par tips:

1. Brug ksh
Dave Korn analyseret alle de angreb på shell-scripts og lukkede så mange huller, som han kunne. Især ksh er immune over for IFS baseret angreb. Også hvis den konstaterer, at det vil interaktive med en effektiv uid af root sammen med en reel uid, der ikke er rod, det vil bruge sine root myndighed at fastsætte den effektive uid til den virkelige uid forud for udstedelse af en prompt.

2. Control PATH
Udtrykkeligt angive din PATH variabel som det første skridt i dit script. Gør listen over mapper så kort som muligt. Du må ikke starte eller afslutte listen med et kolon eller har to på hinanden følgende koloner. Og ikke bringer. eller .. på listen. Udtrykkeligt eksport PATH. Og sikre, at hvert bibliotek nævnt i PATH er skrives kun ved roden. For eksempel, / usr / local / bin er på vej, så ud over det indlysende behov for / usr / local / bin er ikke-skrivbar, skal du også sørge for, at /, / usr, / usr / local er alle ikke skrives. Hvis / usr / local er monteret filsystem, skal det ikke være muligt for en ikke-root-bruger til at sørge for, / usr / local skal umonterede. Kan du yderligere beskytte dit script ved at påberåbe sig PATH så lidt som muligt. Så, for eksempel ved at bruge "/ usr / bin / rm", snarere end blot "rm".

Bemærk: selv om jeg brugte / usr / local / bin som et eksempel, jeg vil modsætte sig at lægge / usr / local / bin i vejen for en suid script. Igen: gøre listen over mapper så kort som muligt. Jeg vil sjældent gå ud over "PATH \u003d / usr / bin" i en suid script.

3. Control IFS
Indstil IFS til et rum, en fane og et newline. Og derefter eksportere IFS. Mens ksh er immune til IFS angreb, nogle andre tankene ikke er immune. Noget, du gør i din script indirekte kan påberåbe sig en anden skal.

4. Sørg for, at scriptet kan ikke skrive
De fleste versioner af UNIX disse dage vil fjerne suid bit på en fil, som den er skrevet af en proces, der ejes af en bruger anderledes end ejeren af filen. Men ikke afhængige af, at adfærd.

5. Udfører ikke direkte eller indirekte enhver bruger leveret input
Du skal sikre, at brugernes input er aldrig leveret til tanken at fortolke som eksekverbar kode. Hvis du ikke ved hvordan man kan sikre dette, bør du ikke bearbejde brugerinput. Bemærk, at parametrene for script skal betragtes brugerinput.

6. Vær forsigtig, hvis du påberåbe programmer at søge input fra brugeren
Må ikke påberåbe programmer, der tillader brugeren at udføre vilkårlige programmer. For eksempel ikke bede brugeren om at VI en fil. VI tilbyder en måde for brugeren at udføre en subshell. Ja, ksh's built-in beskyttelse vil beskytte dig, hvis brugeren påberåber ksh interaktivt. Men desværre andre tanke eksisterer. Og brugeren behøver ikke en interaktiv skal med VI. En kommando gerne ":! Rm / etc / passwd" vil arbejde fra VI og det er ikke ved hjælp af en interaktiv skal.

Disse skridt vil gå langt i retning af at sikre alle suid scripts du skriver, men jeg kan ikke garantere, at de er nok til at helt sikkert et script.

Opfundet af Dennis Ritchie

Begrebet stammer med Dennis Ritchie:

>From dmr Thu Jan 10 04:25:49 1980 remote from research
The system has been changed so that if a file being executed
begins with the magic characters #! , the rest of the line is understood
to be the name of an interpreter for the executed file.
Previously (and in fact still) the shell did much of this job;
it automatically executed itself on a text file with executable mode
when the text file's name was typed as a command.
Putting the facility into the system gives the following
benefits.

1) It makes shell scripts more like real executable files,
because they can be the subject of 'exec.'

2) If you do a 'ps' while such a command is running, its real
name appears instead of 'sh'.
Likewise, accounting is done on the basis of the real name.

3) Shell scripts can be set-user-ID.

4) It is simpler to have alternate shells available;
e.g. if you like the Berkeley csh there is no question about
which shell is to interpret a file.

5) It will allow other interpreters to fit in more smoothly.

To take advantage of this wonderful opportunity,
put

	#! /bin/sh

at the left margin of the first line of your shell scripts.
Blanks after ! are OK.  Use a complete pathname (no search is done).
At the moment the whole line is restricted to 16 characters but
this limit will be raised.


From uucp Thu Jan 10 01:37:49 1980

#! /usr/bin/sh -- # -*- perl -*- -p
eval 'exec perl -S $0 ${1+"$@"}'

Desuden, om systemer, der understøtter eksekverbare scripts (den "#!" Konstruere), anbefales det, at programmer, der bruger eksekverbare scripts installere dem vha. getconf-v for at fastslå råtankens stinavn og opdatere "#!" script passende, da det er ved at blive installeret (for eksempel med sed).