Inledning

Ursprungligen vi bara hade ett skal på Unix. När sprang ett kommando skalet skulle försöka att åberopa en av exec () innebär att man på det. Det kommandot en körbar, den exec skulle lyckas och kommandot körs. Om exec () misslyckades, tanken skulle inte ge upp, i stället skulle försöka tolka kommandot fil som om den vore ett shell script. Detta fungerar bra så länge finns det bara ett skal i systemet. Men om du använder ett skal som din interaktiva och vill köra ett script skrivet i ett annat skal språk?

Det är här #! trick kommer in idén att använda # företräda en kommentar grundar csh och snabbt läggas till Bourne-skal. Nu tankskal vet att ignorera saker efter ett #. Så vi kan lägga till en ledande online något i stil med "#! / Usr / bin / ksh. Så tanken här är bara en kommentar. Men om kärnan försöker köra en fil med denna linje kommer det att exec angiven tolk och låt manus till den. Så skalskript blivit körbar ganska likt riktiga exekverbara filer är. Nu när ett skal försöker exec ett shell script, det lyckas.

Vad händer om du lämnar bort #! linje? Tja, kärnan exec att misslyckas. Din genomsnittliga skal kommer sedan försöker köra scriptet själv. Några tankar att försöka inspektera script för att försöka gissa språket. Detta är inte bra. Du kan köra ksh som din interaktiva skal och skriva ksh skript. Om du senare byta till bash som ett interaktivt skal, några av dina skript kan fortsätta att köra medan andra misslyckas. Även linje är en kommentar som ger en viktig ledtråd till en programmerare som tittar på skript för att förstå det. Att veta vilket språk författaren försöker använda är en stor hjälp.

Samtidigt som jag har använt termen "skal", som faktiskt har den här tekniken kan användas med många program som inte skal. Här är ett "script" för att visa en multiline meddelande:

#! /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 på #! Line

Vi kan säga med säkerhet att de första 2 tecken måste "#!". Eller kan vi? Många system, verkar det som, är villiga att ta bort ledande blanktecken. Min rekommendation är att börja med #!. Det traditionella.

Nästa det kan vara en valfri plats. Vissa handlingar säger att detta utrymme behövs, men så långt som vem som helst kan bestämma bara Unix release att kräva utrymmet var en ögonblicksbild utsättning av BSD 4.1 ... detta inte var en allmän utsättning). Faktiskt verkar det som du kan ha flera platser om du vill. Och en del tester med TAB tecken har gjort och verkar fungera. Min rekommendation är att följa med noll eller ett mellanslag.

Därefter kommer den fullständiga sökvägen till tolk och som alla fullständiga sökvägar måste det börja med ett /. Oj, ett annat undantag ... Linux-kärnan (minst version 2.0.34) är beredd att acceptera en relativ sökväg. Min rekommendation är inte gör det.

Vi kan göra. Eller vi kan ha valfritt blanktecken som leder till vår enda argument. Förutom att vissa versioner av FreeBSD hantera flera argument.

De flesta versioner av BSD och HP-UX kommer band avslutande blanktecken. Andra versioner av Unix behandla avslutande blanktecken som giltiga tecken. Och ett par versioner av BSD kan godta en avslutande kommentar avgränsas av ett # tecken.

Hur länge kan linjen bli? Några versioner av Unix anger gränsen så låg som 32 tecken. FreeBSD tydligen kan hantera 8192 tecken.

Minst linjen alltid slutar med Unix standard \ n tecken, eller hur? Tja, inte alltid. Vissa versioner av Unix kommer att tolerera ett \ r \ n slutar och band utanför \ r medan andra inte kommer att göra det.

Detta är inte som standard eftersom det kan vara ...

Argument 0 av processen, inte Script

Det finns ett annat sätt att genomförandet kan variera. Tänk perl skript som sprang jag ar i slutet av del 1. Mitt skal gjorde den ungefärliga motsvarighet till
execl ( ". / perlargs" ". / perlargs", "En", "två", "tre", (char *) NULL)
och kärnan omvandlas det till den ungefärliga motsvarigheten till
execl ( "/ usr / local / bin /perl" "/ usr / local / bin /perl", "-W", ". / Perlargs", "en", "två", "tre", (char *) NULL)

Markerat i rött är argumentet noll som konventionellt är densamma som den väg av programmet genomförs. En anmärkningsvärd utförandet är att logga in programmet kommer att ställa det till saker som "-ksh. Ursprungligen körbara skalskript hade argumentet 0 inställt på namnet på skriptet i stället namnet på tolk. Dessa dagar, namnet på den tolk är gemensamma. Den sista håll ut jag känner till är HP-UX där argumentet 0 till namnet på skriptet.

När körbara skalskript först infördes de hedrad av suid bit. Detta var en katastrof för säkerheten. Fundera ett skriptanrop / usr / sbin / katastrof. Och vi gjorde:
chown root / usr / sbin / katastrof
chmod 4755 / usr / sbin / katastrof
Naturligtvis, /, / usr, / usr / sbin endast skrivbara av root. Och manuset är i sig bara:
#! / bin / sh
Det stämmer. Skriptet är en enda rad utan dolda tecken. Skalet kommer att ignorera det eftersom det är en kommentar och sedan stänga eftersom det inte finns några andra linjer. Detta skript är redan osäker och är utsatta för två olika attacker.

Attack 1: länk till-i

Om vi gör:
ln-s / usr / sbin / katastrof. /-i
och låta verkställa vår nya symbolisk länk kallad "-i". Om vi verkställa de verkliga / usr / sbin / katastrof, vi gör motsvarande:
execl ( "/ bin / sh", "/ usr / sbin / katastrof", "/ usr / sbin / katastrof", (char *) NULL)
Inga problem där. Det är vad vi väntat. Men när vi kör kopia särskild länk kallad "-i" vi gör:
execl ( "/ bin / sh", "-i", "-i", (char *) NULL)
Detta orsakar suid tanken att fungera som ett interaktivt skal! Skalet var snabbt modifieras för att acceptera ett enda bindestreck som i slutet av växlar inställningen argument. Så vi ändrar vår en linje script för att läsa:
#! / bin / sh --
Nu samma trick skulle resultera i:
execl ( "/ bin / sh", "-i", "-", "-i", (char *) NULL)
Augument noll är fortfarande "-i", men detta är ofarligt. Det kan även vara användbara eftersom det gör denna attack mer märkbar med ps kommandot.

Attack 2: Ändra länk

Detta är svårare att förklara. Liksom tidigare kommer vi göra en symbolisk länk till skriptet under attack, men den här gången namnet spelar ingen roll. Då kommer vi köra skriptet via vår nya symbolisk länk. Då vi snabbt ändra den symboliska länken för att peka till en ond script. Vi vill ändra vad den symboliska länken pekar på efter kärnan öppnar det men innan tolk öppnar det. Detta är en ras villkor och det kommer inte att fungera varje gång. Det kräver också lite smart planering att dra detta ett av. Men gjort rätt, kommer vi att ha vår onda skript körs som root.

Suid Skript Inaktiverad

Eftersom det inte var möjligt att skriva en säker suid shell script, begreppet suid skalskript togs bort från Unix. Runt denna Temne programmet sudo skrevs och detta till stor del oviated behovet av suid skalskript. Jag tror inte någon version av Unix släppts under de senaste 15 åren har dessa problem. (Och om jag gjorde skulle jag inte ha diskuterat dessa attacker. ) Nu hoppas jag att ni kan förstå varför många gamla Temne system admins (som jag själv) har fortfarande en svag bild av suid skalskript.

Återlämnandet av Suid Skript

Solaris stöder nu suid skalskript men är immuna mot dessa attacker. Det gör detta genom att se till att scriptet öppnas bara en gång vid en suid script. Om suid biten har angetts, Solaris använder fd filsystem kommer att gå igenom manus till tolk. Hade min perlargs script varit suid på Solaris, skulle det ha körts något liknande:
execl ( "/ usr / local / bin /perl"," / Usr / local / bin /perl","-W "," / dev/fd/3 "," en "," två "," tre ", (char *) NULL)
och när perl öppnas / dev/fd/3, det blir bara en annan öppen fil descripter pekar i samma fil som oberoende har öppnats som FD 3. Observera att i manus, det finns inget sätt att få namnet annat än / dev/fd/3.

Eftersom det namn som används är dold från intrepreter, finns det ingen skada om det namnet var något konstigt som "-i". Eftersom skriptet öppnas en tid finns det ingen skada om en symbolisk länk plötsligt bytt till en ond script.

Men observera att detta äntligen får vi ett stadium där en en linje manus innehåller bara en kommentar kan säkert köra. Det kan fortfarande finnas andra problem med en dåligt skriven suid script. Om du måste använda suid shell scripts, här är några tips:

1. Använd ksh
Dave Korn analyseras alla de attacker mot skalskript och stängas så många hål som han kunde. I synnerhet ksh är immuna mot IFS baserade attacker. Även om den finner att det kommer en interaktiv med en effektiv uid i roten tillsammans med en verklig uid som inte root, det kommer att använda sin rot myndigheten att fastställa det faktiska uid till de verkliga uid före utfärdar en prompt.

2. Control PATH
Uttryckligen ange din PATH variabel som ett första steg i ditt manus. Gör kataloglistan så kort som möjligt. Får inte börja eller avsluta listan med ett kolon eller har två kolon. Och du behöver inte sätta. eller .. i listan. Uttryckligen export PATH. Och se till att varje katalog i PATH är skrivbar bara av root. Till exempel / usr / local / bin är på vägen, utöver det uppenbara behovet av / usr / local / bin som inte är skrivbar, du måste också se till att /, / usr, / usr / local är alla inte skrivbar. Om / usr / local är monterade filsystem, det får inte vara möjligt för en icke-root-användare att se till att / usr / local vara omonterade. Du kan ytterligare skydda dina manus med hjälp av PATH så lite som möjligt. Så till exempel använda "/ usr / bin / rm" snarare än bara "rm".

Obs: jag / usr / local / bin som ett exempel skulle jag starkt motsätter sig att lägga / usr / local / bin i vägen för en suid script. Återigen: göra kataloglistan så kort som möjligt. Jag vill sällan gå längre än "PATH \u003d / usr / bin" i en suid script.

3. Control IFS
Ställ IFS till ett utrymme, en flik och en newline. Och sedan exportera IFS. Även ksh är immun mot den IFS attack, några andra tankar inte är immuna. Något du gör i ditt manus indirekt kan åberopa en annan skal.

4. Se till att skriptet kan inte skriva
De flesta versioner av Unix dessa dagar kommer att ta bort suid bit på en fil som den är skriven av en process som ägs av en användare annat än ägaren av filen. Men inte är beroende av att beteendet.

5. Försök inte utföra direkt eller indirekt alla användare levereras ingång
Du måste se till att användardata aldrig levererats till tanken att tolka som exekverbar kod. Om du inte vet hur man skall se detta, så ska du inte behandla alla användardata. Observera att de parametrar som skriptet måste betraktas användardata.

6. Var försiktig om du åberopa program att begära in synpunkter från användarna
Inte åberopa program som låter användaren köra godtyckliga program. Till exempel, inte uppmana användaren att VI en fil. VI erbjuder ett sätt för användaren att utföra en subshell. Ja, ksh inbyggda skydd skyddar dig om användaren åberopar ksh interaktivt. Men tyvärr, andra tankar finns. Och användaren behöver inte ett interaktivt skal med VI. Ett kommando som ":! Rm / etc / passwd" kommer att arbeta från VI och detta är inte med hjälp av en interaktiv skal.

Dessa steg kommer att gå en lång väg mot att säkra en suid skript du skriver, men jag kan inte garantera att de är tillräckligt för att helt säkert ett manus.

Uppfanns av Dennis Ritchie

Begreppet har sitt ursprung 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+"$@"}'

Vidare på system som stödjer körbara skript (det "#!" Konstruera), rekommenderas det att program som använder körbara skript installera dem med getconf-v för att bestämma skal sökvägen och uppdatera "#!" script lämpligt eftersom det är installerat (till exempel med sed).