Home  |  Map  |  Index  |  Zoek

Convert to GutenPalm or to PalmDoc door Frédéric Raynal, Christophe Blaess, Christophe Grenier <pappy(at)users.sourceforge.net, ccb(at)club-internet.fr, grenier(at)nef.esiea.fr> Over de auteur: Christophe Blaess is een onafhankelijke luchtvaart ingenieur. Hij is een Linux fan en werkt veel met dit systeem. Hij coordineert de vertaling van de man pages zoals die te vinden zijn op de site van het Linux Documentation Project. Christophe Grenier is een 5e jaars student aan de ESIEA, hij werkt daar ook als systeembeheerder. Hij is gek van computer beveiligingssystemen. Frédéric Raynal gebruikt Linux nu al jaren omdat het niet vervuilend is, niet opgepept wordt met hormonen, MSG of beendermeel... maar alleen met bloed, zweet, tranen en kennis. Vertaald naar het Nederlands door: Hendrik-Jan Heins <hjh(at)passys.nl> Inhoud: Inleiding Eerste voorbeeld Laten we meer realistisch te werk gaan Mogelijke verbeteringen Richtlijnen Race conditions met betrekking tot de bestandsinhoud Tijdelijke bestanden Conclusie Links Talkback voor dit artikel

Veiligheidslekken vermijden bij het programmeren - Deel 5 : "Race Conditions"

Kort:

Dit vijfde artikel van deze serie is gericht op veiligheidslekken gerelateerd aan multi-tasken. Een zogenaamde "race condition" ontstaat wanneer verschillende processen tegelijk dezelfde bronnen gebruiken (bestanden, apparaten of geheugen) en ieder proces meent de exclusieve rechten op deze bron te hebben. Dit leidt tot moeilijk op te sporen bugs en veiligheidsgaten die de totale systeemveiligheid kunnen schaden.

 

Inleiding

De algemene definitie van "race conditions" is de volgende: een proces wil exclusieve rechten op een systeembron. Dit proces controleert of er geen ander proces is dat de bron al gebruikt en gebruikt de bron dan wanneer nodig. De "race condition" treedt op op het moment dat een ander proces de bron vertraagd probeert aan te spreken tussen het moment van checken door het eerste proces en voordat het eerste proces de bron daadwerkelijk over heeft genomen. De hierna optredende effecten kunnen varieren. Het klassieke voorbeeld hiervan in OS theorie is het vastlopen van beide processen. Maar meestal leidt het tot een fout binnen een applicatie of zelfs tot een veiligheidsgat wanneer een proces per ongeluk bevoordeeld wordt door de rechten van een ander proces.

Wat we tot nu toe een "bron" hebben genoemd kan verschillende vormen hebben. Hier focussen we met name op "race conditions" die ontdekt en gecorrigeerd worden door de Linux kernel zelf die te maken hebben met gelijktijdige toegang tot geheugengebieden. In dit artikel focussen we op systeem applicaties met als bronnen de bestandssysteem nodes. Dit gaat niet alleen over gewone bestanden maar ook om directe toegang tot apparaten door speciale koppelpunten in de /dev/ directory.

Aanvallen die bedoeld zijn om de systeemveiligheid in gevaar te brengen worden meestal gedaan op "Set-UID" applicaties omdat de aanvaller dan kan profiteren van het feit dat hij de eigenaar van het betreffende uitvoerbare bestand wordt. Echter staan "race conditions" de uitvoering van "aangepaste" code meestal niet toe, dit in tegenstelling tot eerder bediscussieerde veiligheidsgaten (zoals buffer overflow, format strings etc.), "race conditions" staat over het algemeen de uitvoering van aangepaste code niet toe. Maar er wordt gebruik gemaakt van de bronnen van een programma terwijl het draait. Dit type aanval kan ook worden gericht tegen "normale" utilities ( die niet werken met "Set-UID"), de kraker legt een hinderlaag voor een andere gebruiker, liefst de root, om op het moment dat die een bepaalde applicatie draait de bronnen van die applicatie de openen. Dit geldt bijvoorbeeld voor het schrijven van een bestand ( zoals: ~/.rhost met daarin de string "+ +", dit staat directe toegang toe vanaf iedere machine en zonder wachtwoord), of voor het lezen van een vertrouwelijk bestand (gevoelige commerciele gegevens, medische gegevens, wachtwoord bestanden, coderings sleutels, etc).

In tegenstelling tot de veiligheidsgaten die besproken zijn in onze voorgaande artikelen, is dit veiligheidsgat gerelateerd aan iedere applicatie en niet alleen aan "Set-UID" utilities en systeem servers of deamons.

Eerste voorbeeld

Laten we eens kijken naar het gedrag van een "Set-UID" programma dat bepaalde gegevens in een bestand van een bepaalde gebruiker wil bewaren. We zouden bijvoorbeeld kunnen kijken naar een mail transport pakket zoals sendmail. Laten we er vanuit gaan dat de gebruiker de naam van een back-up bestand mag geven en een bericht mag schrijven in dat bestand. Dit is onder bepaalde omstandigheden noodzakelijk en logisch. De applicatie moet dan controleren of het bestand daadwerkelijk van de gebruiker is die het programma opstartte. Het zal ook controleren of het bestand geen symbolische koppeling naar een systeembestand. Vergeet niet dat het bestand "Set-UID root" is, hierdoor mag het ieder bestand op de machine veranderen. Op de hier beschreven manier zal het programma de identiteit van de eigenaar van het bestand vergelijken met de eigenaar z'n eigen UID. Laten we iets als het volgende schrijven:

1     /* ex_01.c */
2     #include <stdio.h>
3     #include <stdlib.h>
4     #include <unistd.h>
5     #include <sys/stat.h>
6     #include <sys/types.h>
7
8     int
9     main (int argc, char * argv [])
10    {
11        struct stat st;
12        FILE * fp;
13
14        if (argc != 3) {
15            fprintf (stderr, "usage : %s file message\n", argv [0]);
16            exit(EXIT_FAILURE);
17        }
18        if (stat (argv [1], & st) < 0) {
19            fprintf (stderr, "can't find %s\n", argv [1]);
20            exit(EXIT_FAILURE);
21        }
22        if (st . st_uid != getuid ()) {
23            fprintf (stderr, "not the owner of %s \n", argv [1]);
24            exit(EXIT_FAILURE);
25        }
26        if (! S_ISREG (st . st_mode)) {
27            fprintf (stderr, "%s is not a normal file\n", argv[1]);
28            exit(EXIT_FAILURE);
29        }
30
31        if ((fp = fopen (argv [1], "w")) == NULL) {
32            fprintf (stderr, "Can't open\n");
33            exit(EXIT_FAILURE);
34        }
35        fprintf (fp, "%s\n", argv [2]);
36        fclose (fp);
37        fprintf (stderr, "Write Ok\n");
38        exit(EXIT_SUCCESS);
39    }

Zoals we in het eerste artikel al hebben uitgelegd, zou het beter zijn wanneer een "Set-UID" applicatie tijdelijk z'n privileges los zou laten en het bestand zou openen met behulp van de UID van de betreffende gebruiker. In feite werkt de hierboven uitgelegde situatie als een deamon, het verleent diensten aan iedere gebruiker. Het draait altijd onder de root ID, maar het zou moeten checken met de UID in plaats van de eigen UID. Maar we houden het geschetste systeem aan, ook al is het niet geheel realistisch, aangezien het het probleem eenvoudiger voorstelt terwijl er gemakkelijk "gebruikt gemaakt" kan worden van het veiligheidsgat.

Zoals we nu kunnen zien, begint het programma met de benodigde controles, dus controleren of het bestand bestaat, of het van de gebruiker is en of het een normaal bestand is. Vervolgens opent het het bestand en schrijft het bericht. Dat is waar het veiligheidsgat ontstaat! Of, om exacter te zijn, het ontstaat in de tijd tussen het lezen van de bestandseigenschappen met stat() en het openen met fopen(). Deze tijdsspanne is vaak extreem kort, maar een aanvaller kan er gebruik van maken om de bestandseigenschappen te veranderen. Om de aanval nog makkelijker te maken, bouwen we een regel in die er voor zorgt dat het proces rust tussen twee operaties, waardoor er meer tijd is om de veranderingen te realiseren. Regel 30 wordt veranderd (voorheen was deze leeg):

30        sleep (20);

Dit moet u eerst geimplementeerd worden, maak de applicatie "Set-UID root". En, let op, dit is belangrijk, maak een back-up van het wachtwoord bestand /etc/shadow :

$ cc ex_01.c -Wall -o ex_01
$ su
Password:
# cp /etc/shadow /etc/shadow.bak
# chown root.root ex_01
# chmod +s ex_01
# exit
$ ls -l ex_01
-rwsrwsr-x 1 root  root    15454 Jan 30 14:14 ex_01
$

Nu is alles klaar voor de aanval. We beginnen in een directory waarvan wij de eigenaar zijn. We hebben een "Set-UID" utility (hier is dat dus ex_01) met een veiligheidsgat and we willen de eerste regel met betrekking tot de root login in het wachtwoord-bestand /etc/shadow vervangen door een regel met een leeg wachtwoord.

Eerst maken we een "fic" bestand dat van ons is:

$ rm -f fic
$ touch fic

Vervolgens draaien we onze applicatie in de achtergrond "om 'em voor te zijn". We vragen de applicatie om een string in dat bestand weg te schrijven. Hij controleert wat gecontroleerd moet worden en slaapt een tijdje voordat hij daadwerkelijk het bestand opent.

$ ./ex_01 fic "root::1:99999:::::" &
[1] 4426

De inhoud van de root regel komt van de shadow (5) man pagina's, het belangrijkste is het lege tweede veld (geen wachtwoord). Zolang het proces slaapt, dit is ongeveer 20 seconden, kunnen we het "fic" bestand verwijderen en het vervangen door een link (symbolisch of fysiek, dat maakt niet uit) naar het /etc/shadow bestand. Onthoud wel dat iedere gebruiker een link naar een bestand in een directory die van hem is kan maken, zelfs als hij de inhoud niet kan lezen, (dit kan ook altijd in /tmp, verderop meer hierover). Het is echter niet mogelijk om een copie te maken van zo'n bestand, omdat dat de volledige leesrechten vereist.

$ rm -f fic
$ ln -s /etc/shadow ./fic

Vervolgens vragen we de shell om het ex_01 proces terug te plaatsen naar de voorgrond met het "fg" commando and wachten we tot het geeindigd is:

$ fg
./ex_01 fic "root::1:99999:::::"
Write Ok
$

Voilà ! Dat was het, het /etc/shadow bestand bevat slechts een regel die aangeeft dat root geen wachtwoord heeft. Je gelooft het niet?

$ su
# whoami
root
# cat /etc/shadow
root::1:99999:::::
#

Om ons experiment af te ronden zetten we het oude wachtwoord-bestand terug:

# cp /etc/shadow.bak /etc/shadow
cp: replace `/etc/shadow'? y
#

Laten we meer realistisch te werk gaan

We hebben met succes gebruik kunnen maken van een "race condition" in een "Set-UID" utility. Het is natuurlijk wel zo dat dit programma erg behulpzaam was door 20 seconden te wachten om ons de tijd te geven om het bestand te veranderen. In een echte applicatie bestaat de "race condition" slechts een korte tijd. Hoe kunnen we daar gebruik van maken?

Normaal gesproken maakt een kraker gebruik van een "brute force" aanval, waarbij er honderden, duizenden of zelfs tienduizenden pogingen gedaan worden met behulp van scripts om dit proces te automatiseren. Het is mogelijk om de kansen op het succesvol exploiteren van een veiligheidsgat te vergroten met behulp van enkele trucs die het tijdsgat tussen de twee operaties die het programma moet uitvoeren vergroot. Het plan is om het doelproces te vertragen om zo gemakkelijker het bestand te kunnen modificeren. Verschillende benaderingen kunnen ons helpen om dit doel te bereiken:

• Het zo veel mogelijk verlagen van het prioriteitsniveau van het aan te vallen proces, dit kan door bijvoorbeeld gebruik te maken van "nice -n 20";
• Door de systeembelasting te vergroten door meerdere processen te draaien in tijdrovende loops (zoals bijvoorbeeld "while (1)" ;
• De kernel staat het debuggen van "Set-UID" programma's niet toe, maar het is mogelijk om een "pseudo-stap-voor-stap" uitvoering te forceren door het sturen van een "SIGSTOP-SIGCONT" signaal, hierdoor wordt het mogelijk om een proces tijdelijk stil te leggen (zoals ook mogelijk is met de toetscombinatie "ctrl-Z" in een dos-venster) en om het opnieuw te starten als dat nodig is.

Ieder van deze methodes, hoewel saai en repetatief, maakt het mogelijk om gebruik te maken van veiligheidsgaten gabaseerd op "race conditions" en ze zijn absoluut bruikbaar! Laten we nu proberen de meest effectieve oplossingen te vinden.

Mogelijke verbeteringen

Het probleem dat hierboven besproken is, gaat uit van de mogelijkheid om de karakteristieken van een object te veranderen in het tijdsgat tussen twee operaties, terwijl de hele actie zo continu doorloopt als mogelijk is. In de voorgaande situatie, had de verandering niets te maken met het bestand zelf. Trouwens, dit zou een vrij lastige actie geweest zijn als deze uitgevoerd zou worden door een gewone gebruiker, aangezien deze modificaties aan het /etc/shadow bestand niet zomaar gemaakt mogen worden. De veranderingen zijn in feite gebaseerd op de koppeling tussen de bestaande bestandsnode in de "nametree" en het fysieke bestand zelf.Onthoud hierbij wel dat de meeste systeemcommando's (zoals rm, mv, ln, etc.) werken met de bestandsnaam, niet de bestandsinhoud. Zelfs wanneer je een bestand verwijdert (met behulp van "rm" en het "unlink ()" commando, de inhoud is nu echt verwijderd op het moment dat de laatste fysieke link, het laatste referentiepunt, verwijderd is.

De fout die gemaakt is in het bovenstaande programma is dat de associatie tussen de bestandsnaam en de bestandsinhoud onveranderlijk zijn, of tenminste onderanderd, tussen de "stat()" en de "fopen()" operatie. Met andere woorden: het voorbeeld van een fysieke koppeling zou voldoende moeten zijn om aan te tonen dat deze koppeling helemaal geen permanente koppeling is. Laten we een voorbeeld uitwerken met dit type koppeling. In een diretory, waarvan wij de eigenaar zijn, maken we een nieuwe koppeling naar een systeembestand. We veranderen de bestandseigenaar en de toegangsinstellingen van het bestand niet. Met het ln commando met de -f optie wordt de creatie van het bestand geforceerd, zelfs wanneer er al een bestand met die naam bestaat:

$ ln -f /etc/fstab ./myfile
$ ls -il /etc/fstab myfile
8570 -rw-r--r--   2 root  root  716 Jan 25 19:07 /etc/fstab
8570 -rw-r--r--   2 root  root  716 Jan 25 19:07 myfile
$ cat myfile
/dev/hda5   /                 ext2    defaults,mand   1 1
/dev/hda6   swap              swap    defaults        0 0
/dev/fd0    /mnt/floppy       vfat    noauto,user     0 0
/dev/hdc    /mnt/cdrom        iso9660 noauto,ro,user  0 0
/dev/hda1   /mnt/dos          vfat    noauto,user     0 0
/dev/hda7   /mnt/audio        vfat    noauto,user     0 0
/dev/hda8   /home/ccb/annexe  ext2    noauto,user     0 0
none        /dev/pts          devpts  gid=5,mode=620  0 0
none        /proc             proc    defaults        0 0
$ ln -f /etc/host.conf ./myfile
$ ls -il /etc/host.conf myfile 
8198 -rw-r--r--   2 root  root   26 Mar 11  2000 /etc/host.conf
8198 -rw-r--r--   2 root  root   26 Mar 11  2000 myfile
$ cat myfile
order hosts,bind
multi on
$

De opdracht /bin/ls met de -i optie laat het nummer van de inode aan het begin van de regel zien. Zoals we nu kunnen zien, wijst de zelfde naam naar twee fysiek verschillende inodes.

Maar eigenlijk willen we dat de functies die de toegang tot een bestand conroleren altijd naar dezelfde inhoudsgegevens en dezelfde inode wijzen. En dat is mogelijk! De kernel zelf houdt automatisch deze associaties bij wanneer hij ons een bestands "descriptor" presenteert. Op het moment dat we een bestand openen om de inhoud te lezen, met het commando open() geeft een systeemoproep een getalswaarde, dat is de "descriptor", en associeert het met het fysieke bestand met behulp van een interne tabel. En alles wat we hierna lezen is onderdeel van deze bestandsinhoud. Het maakt niet uit wat er onderwijl gebeurt met de bestandsnaam tijdens de bestands-open operatie.

Het bovenstaande moet benadrukt worden: Zodra een bestand geopend is, maakt het niet uit wat er gebeurd met de bestandsnaam, ook het verwijderen ervan maakt niet uit voor de bestandsinhoud Zolang er maar een proces draait dat een "descriptor" voor het bestand aangeeft, wordt de inhoud van het bestand niet verwijderd van de schijf, zelfs niet als de bestandsnaam verdwijnt uit de directory waar hij stond. De kernel beheert de associatie van het bestand tussen het open() commando en het close() commando door het bestand te voorzien van een "descriptor" die blijft bestaan tot het proces beeindigd wordt.

Dus dat is onze oplossing! We kunnen het bestand openen en dan de togeangsrechten controleren door de "descriptor" karakteristieken te bekijken en niet de bestandsnaam karakteristieken. Dit kan worden gedaan met behulp van het fstat() commando (het werkt net zo als het stat() commando), maar het controleert de bestands-"descriptor" en niet het pad. Om de inhoud van het bestand te bekijken met behulp van de "descriptor" kunnen we het fdopen() commando gebruiken ( dit werkt net zo als het fopen() commando), maar het maakt gebruik van de "descriptor" in plaats van de bestandsnaam. En dus ziet het programma er nu als volgt uit:

1    /* ex_02.c */
2    #include <fcntl.h>
3    #include <stdio.h>
4    #include <stdlib.h>
5    #include <unistd.h>
6    #include <sys/stat.h>
7    #include <sys/types.h>
8
9     int
10    main (int argc, char * argv [])
11    {
12        struct stat st;
13        int fd;
14        FILE * fp;
15
16        if (argc != 3) {
17            fprintf (stderr, "usage : %s file message\n", argv [0]);
18            exit(EXIT_FAILURE);
19        }
20        if ((fd = open (argv [1], O_WRONLY, 0)) < 0) {
21            fprintf (stderr, "Can't open %s\n", argv [1]);
22            exit(EXIT_FAILURE);
23        }
24        fstat (fd, & st);
25        if (st . st_uid != getuid ()) {
26            fprintf (stderr, "%s not owner !\n", argv [1]);
27            exit(EXIT_FAILURE);
28        }
29        if (! S_ISREG (st . st_mode)) {
30            fprintf (stderr, "%s not a normal file\n", argv[1]);
31            exit(EXIT_FAILURE);
32        }
33        if ((fp = fdopen (fd, "w")) == NULL) {
34            fprintf (stderr, "Can't open\n");
35            exit(EXIT_FAILURE);
36        }
37        fprintf (fp, "%s", argv [2]);
38        fclose (fp);
39        fprintf (stderr, "Write Ok\n");
40        exit(EXIT_SUCCESS);
41    }

Nu kan niets, na regel 20, het gedrag van ons programma beinvloeden (dus ook niet: verwijderen, hernoemen, koppelen); de inhoud van het originele, fysieke, bestand blijft behouden.

Richtlijnen

Wanneer je een bestand verandert is het van belang om je er van te verzekeren dat de associatie tussen de representatie van de inhoud en de echte inhoud gelijk is. We gebruiken bij voorkeur de volgende commando's om het fysieke bestand te veranderen met behulp van de geactiveerde "descriptor" in plaats van met het pad en de naamsgegevens van het bestand:

Nu moet natuurlijk het bestand worden geopend in de gewenste modus, dit kan met het commando open() (Vergeet het derde argument niet wanneer je een nieuw bestand maakt). Meer over open() later wanneer we het tijdelijke bestandsprobleem bespreken.

We wijzen er met klem op dat het zeer belangrijk is om de feedback die de commando's genereren te controleren. Om een voorbeeld te geven, dat welliswaar niets te maken heeft met "race conditions", de problemen die gevonden kunnen worden in oude /bin/login implementaties doordat er geen foute code controle plaatsvindt. Deze applicatie voorzag in een automatische "root" toegang wanneer het /etc/passwd niet gevonden werd. Dit lijkt een acceptabele oplossing wanneer we over een beschadigd bestandssysteem praten. Echter controleren of het onmogelijk was om het bestand te openen in plaats van controleren of het bestand echt bestaat is minder acceptabel. Het aanroepen van /bin/login na het openen van het maximaal toegestane aantal "descriptors" geeft iedere gebruiker toegang tot het systeem als "root".....Laten we deze uitweiding beeindigen met benadrukken hoe belangrijk het is om te controleren, en dan niet alleen de systeemmeldingen "succes" of "error", maar de errorcodes zelf ook en dan wel voordat je iets gaat veranderen aan de veiligheidsinstellingen van het systeem.

Race conditions met betrekking tot de bestandsinhoud

Eeen programma dat betrekking heeft op systeemveiligheid zou niet moeten vertrouwen op exclusieve toegang tot de inhoud van een bestand. Het is belangrijk om de risico's van een "race condition" in dat zelfde bestand goed te beheren en beheersen. Het grootste gevaar komt van een gebruiker die meerdere versies van een Set-UID root applicatie tegelijk draait of met een en dezelfde deamon meerdere connecties tegelijk initieert, in de hoop een "race condition" te genereren, om op dat moment een systeembestand op een ongewone wijze te veranderen.

Om te vermijden dat het programma gevoelig is voor dit soort situaties, is het noodzakelijk om een exclusief toegangsmechanisme tot de inhoud van het bestand in te stellen. Dit is hetzelfde probleem als het probleem in databases gevonden kan worden wanneer verschillende gebruikers gelijktijdig bestandsinhoud mogen opvragen of veranderen. Het principe van "file locking" kan dit probleem opgelost worden.

Wanneer een proces naar een bestand wil schrijven, vraagt het de kernel om het bestand, of een deel ervan, te "locken". Zolang het proces het "lock" in stand houdt, kan geen enkel ander proces het betreffende bestand, of deel ervan, "locken". Een proces kan op dezelfde manier een "lock" aanvragen voordat het de inhoud van een bestand leest om te voorkomen dat de inhoud niet veranderd wordt tijdens de "lock" situatie.

Het systeem is in feite nog slimmer dan dat: de kernel maakt een onderscheid tussen het type "lock" dat nodig is voor het lezen van een bestand en het type dat nodig is voor het schrijven van een bestand. Meerdere processen kunnen gelijktijdig een lees-"lock" op een bestand hebben, omdat geen ervan de inhoud van het bestand zal veranderen. Maar bij schrijven kan maar een proces een "lock" op een bestand hebben, een ander proces kan dan geen "lock" voor schrijven krijgen, maar ook geen "lock" voor lezen.

Er zijn twee "lock"-types (die over het algemeen niet compatible met elkaar zijn). De eerste komt van BSD en maakt gebruik van de flock() operatie. Het eerste argument hierbij is de is de "descriptor" van het bestand waarin je exclusieve toegangwilt hebben en het tweede argument is een symbolische constante die de uit te voeren operatie representeert. De opdracht kan verschillende waardes hebben: LOCK_SH (een lees-"lock"), LOCK_EX (een schrijf-"lock") LOCK_UN (het opheffen van het "lock"). Het systeem blokkeert alle andere aanvragen zolang het proces het bestand beheert. Echter, je kan een binaire OR | van de LOCK_NB constante uitvoeren, zodat het proces met een foutmelding stopt en niet "gelocked" blijft.

Het tweede "lock"-type komt van System V en vertrouwt op de fcntl() systeem operatie, echter deze heeft een wat lastige aanroep. Er is een bibliotheekfunctie fcntl(), die veel lijkt op de systeem operatie, maar deze is veel trager. Het eerste argument van fcntl() is de "descriptor" die het bestand "locked". Het tweede argument representeert de operatie die uitgevoerd moet worden: F_SETLK en F_SETLKW beheren een "lock", waarbij het tweede commando geblokkeerd blijft tot deze mogelijk wordt, terwijl de eerste meteen output genereert als er iets mis gaat. F_GETLK vraagt de "lock"-staat aan van een bestand (dat niet te gebruiken is door de op dat moment draaiende applicaties). Het derde argument is een "pointer" naar een variabele van het struct flock type, dat het "lock" beschrijft. De belangrijke onderdelen voor de flock structuur zijn de volgenden:

We kunnen nu zien dat fcntl() gedeeltes van een bestand kan "locken", maar het kan nog veel meer als je het vergelijkt met het flock() commando. Laten we eens kijken naar een klein programma dat vraagt om een "lock" om een bepaald bestand te lezen dat gedefinieerd kan worden met een argument, bovendien wacht het op de gebruiker die op de "enter" toets moet drukken voordat het eindigt (en dan dus ook de "locks" opent).

1    /* ex_03.c */
2    #include <fcntl.h>
3    #include <stdio.h>
4    #include <stdlib.h>
5    #include <sys/stat.h>
6    #include <sys/types.h>
7    #include <unistd.h>
8
9    int
10   main (int argc, char * argv [])
11   {
12     int i;
13     int fd;
14     char buffer [2];
15     struct flock lock;
16
17     for (i = 1; i < argc; i ++) {
18       fd = open (argv [i], O_RDWR | O_CREAT, 0644);
19       if (fd < 0) {
20         fprintf (stderr, "Can't open %s\n", argv [i]);
21         exit(EXIT_FAILURE);
22       }
23       lock . l_type = F_WRLCK;
24       lock . l_whence = SEEK_SET;
25       lock . l_start = 0;
26       lock . l_len = 0;
27       if (fcntl (fd, F_SETLK, & lock) < 0) {
28         fprintf (stderr, "Can't lock %s\n", argv [i]);
29         exit(EXIT_FAILURE);
30       }
31     }
32     fprintf (stdout, "Druk op de "enter" toets om het "lock" te openen\n");
33     fgets (buffer, 2, stdin);
34     exit(EXIT_SUCCESS);
35   }

We draaien dit programma eerst via een console, dat ziet er als volgt uit:

$ cc -Wall ex_03.c -o ex_03
$ ./ex_03 myfile
Druk op de "enter" toets om het "lock" te openen

    $ ./ex_03 myfile
    Can't lock myfile
    $

Met dit "locking" mechanisme kan je "race conditions" in directories en printer wachtrijen, zoals de lpd daemon, voorkomen door gebruik te maken van flock() om een "lock" te zetten op het /var/lock/subsys/lpd bestand, waardoor er slechts een proces tegelijk toegang heeft. Je kan de toegang tot een systeembestand, zoals /etc/passwd, op een veilige manier beheren, wanneer je gebruik maakt van fcntl() met behulp van de pam bibliotheek wanneer je gebruikersgegevens verandert.

Helaas echter beveiligt het bovenstaande alleen tegen storingen van applicaties die zich correct gedragen, dus eerst de kernel vragen om de juiste manier van toegang voordat ze lezen of schrijven naar een belangrijk systeembestand. We gaan het nu hebben over een "cooperatief lock", dat de vatbaarheid van een applicatie aantoont met betrekking tot de toegang tot gegevens. Helaas kan een slecht geschreven programma ook de inhoud van een bestand vervangen, zelfs als een ander proces, dat zich wel correct gedraagt, een schrijf-"lock" heeft op het betreffende bestand. Hier volgt een voorbeeld. We schrijven een paar letters in een bestand en we "locken" het bet behulp van het eerder gemaakte programma:

$ echo "FIRST" > myfile
$ ./ex_03 myfile
Press Enter to release the lock(s)

    $ echo "SECOND" > myfile
    $

(Enter)
$ cat myfile
SECOND
$

Om dit probleem op te kunnen lossen geeft de Linux kernel de systeem administrator een "locking" mechanisme dat van System V komt. Daardoor is het alleen te gebruiken met fcntl() "locks" en niet met flock() "locks". De systeem administrator kan de kernel vertellen dat de fcntl() "locks" strict zijn, door gebruik te maken van een speciale comninatie van toegangsrechten. Hierna kan geen enkel ander proces een bestand dat "gelocked" is voor schrijven nog openen op zelf naar te schrijven, zelfs niet als root. Deze specifieke combinatie maakt gebruik van de Set-GID bit terwijl de bit die uitvoering toestaat verwijderd is van de groep. Dit kan door middel van het volgende commando gerealiseerd worden:

$ chmod g+s-x myfile
$

# mount
/dev/hda5 on / type ext2 (rw)
[...]
# mount / -o remount,mand
# mount
/dev/hda5 on / type ext2 (rw,mand)
[...]
#

$ ./ex_03 myfile
Press Enter to release the lock(s)

    $ echo "THIRD" > myfile
    bash: myfile: Resource temporarily not available
    $

(Enter)
$ cat myfile
SECOND
$

De administrator en niet de programmeur moet de beslissing om strike bestands "locks" te gebruiken, nemen ( bijvoorbeeld op /etc/passwd, of /etc/shadow). De programmeur moet de manier waarop de gegevens worden geopend controleren, daardoor is hij ervan verzekerd dat zijn applicatie gegevens op een correcte, samenhangende, manier benadert, wanneer de applicatie leest en dat de applicatie geen gevaar is voor andere processen wanneer hij iets wegschrijft, zolang de omgeving correct is onderhouden door de administrator.

Tijdelijke bestanden

Vaak moet een programma tijdelijk gegevens wegschrijven in een extern bestand. Doorgaans wordt er een record in het midden van een sequentieel geordend bestand aangelegd, dit houdt dan ook in dat we een copy maken van het originele bestand in een tijdelijk bestand, The most usual case is inserting a record in the middle of a sequential ordered file, which implies that we make a copy of the original file in a temporary file, while adding new information. Next the unlink() system call removes the original file and rename() renames the temporary file to replace the previous one.

Het openen van een standaard bestand is, mits niet goed uitgevoerd, vaak het begin van een "race condition" die wordt opgestart door een gebruiker met kwade bedoelingen. Veiligheidslekken gebaseerd op tijdelijke bestanden zijn recentelijk aangetroffen in applicaties als bijvoorbeeld Apache, Linuxconf, getty_ps, wu-ftpd, rdist, gpm, inn, etc. Onthoud een paar principes om dit soort problemen te vermijden.

Gewoonlijk worden tijdelijke bestanden gemaakt in de /tmp directory. Hierdoor weet de systeembeheerder waar de tijdelijke data te vinden is. Het is daardoor ook mogelijk om een proramma te schrijven dat de directory periodiek opschoont, door gebruik te maken van cron, door het gebruik van een losse partitie die geformateerd wordt tijdens een boot etc. Normaal gesproken definieert de systeembeheerder de plaats die gereserveerd is voor tijdelijke bestanden in de <paths.h> en <stdio.h> bestanden in de symbolische constantes definities _PATH_TMP en P_tmpdir. Het is dan ook niet verstandig om een andere standaard directory in te stellen dan /tmp, aangezien dat betekent dat je dan ook iedere applicatie opnieuw moet compileren, inclusief de C bibliotheek. In de GlibC routine is echter wel aan te geven waar naartoe wordt geschreven met behulp van de TMPDIR omgevingsvariabele. Zo kan een gebruiker instellen dat tijdelijke bestanden naar een directory die van hem is, worden weggeschreven in plaats van in /tmp. Dit is soms verplicht, bijvoorbeeld wanneer de partitie die is toegewezen aan /tmp te klein is om een applicatie te draaien die veel tijdelijke betsandsruimte nodig heeft.

De /tmp systeem directory is iets speciaals door z'n toegangsrechten:

$ ls -ld /tmp
drwxrwxrwt 7 root  root    31744 Feb 14 09:47 /tmp
$

De zogenaamde Sticky-Bit die gerepresenteerd wordt door de letter t aan het einde of de octale 01000 modus, heeft een speciale betekenis op het moment dat deze wordt toegepast op een directory: alleen de eigenaar van de directory (root ) en de eigenaar van een bestand in deze directory kunnen dit bestand verwijderen. De directory heeft volledige schrijftoegang, iedere gebruiker kan zijn bestanden er in wegschrijven, en er zeker van zijn dat ze beveiligd zijn - tenminste, tot aan de volgende schoonmaakoperatie uitgevoerd door de systeembeheerder.

Ondanks dit alles, kan het gebruik van tijdelijke opslag een paar problemen geven. Laten we beginnen met een alledaagse mogelijkheid, een "Set-UID" root applicatie die communiceert met de gebruiker. Bijvoorbeeld een mail programma. Als dit proces de opdracht krijgt om onmiddelijk te eindigen, bijvoorbeeld SIGTERM of SIGQUIT tijdens een shutdown procedure, dan kan hij proberen de al geschreven maar nog niet verzonden mail "on the fly" te bewaren. Bij oude versies werd dit gedaan in het /tmp/dead.letter bestand. Daarna hoefde de gebruiker alleen nog maar een fysieke link te maken naar het /etc/passwd bestand (dit omdat hij niet mag schrijven in/tmp) met de naam dead.letter voor de mailer (die draait onder UID root) om de inhoud van het nog niet afgemaakte mailtje te kunnen veranderen (toevallig bevat dit ook de volgende regel: "root::1:99999:::::").

Het eerste probleem met dit soort gedrag is het feit dat de bestandsnaam te voorspellen is. Je kan door een keer naar zo'n applicatie te kijken deduceren dat het de bestandsnaam /tmp/dead.letter zal gebruiken. Daarom is de eerste stap het gebruik van een bestandsnaam die per draaiend programma wordt gedefinieerd. Er zijn meerdere bibliotheekfuncties verkrijgbaar die ons kunnen voorzien van een tijdelijke bestandsnaam.

Laten we er van uit gaan dat we zo'n functie hebben die een unieke naam voor ons tijdelijke bestand genereert. Echter aangezien gratis software zoals dit verkrijgbaar is met broncode en al (ook voor de C bibliotheek), is de bestandsnaam echter nog steeds te voorzien, ook al is dat nog vrij lastig. Een kraker kan een symbolische link creeren naar de bestandsnaam die de C bibliotheek genereert. Onze eerste reactie is dan om te controleren of het bestand bestaat voor het te openen. Naief als we zijn, zouden we iets als het volgende kunnen schrijven:

  if ((fd = open (filename, O_RDWR)) != -1) {
    fprintf (stderr, "%s already exists\n", filename);
    exit(EXIT_FAILURE);
  }
  fd = open (filename, O_RDWR | O_CREAT, 0644);
  ...

Dit is duidelijk een typisch geval van een "race condition", waarbij een veiligheidsgat geopend wordt dankzij de gebruiker waardoor het mogelijk wordt om een link naar /etc/passwd te leggen tussen de eerste en tweede open() actie. Deze twee operaties boeten gekoppeld uitgevoerd worden, zonder dat er tussen de twee commando's veranderingen aangebracht kunnen worden. Dit is mogelijk door een specifieke optie van de open() systeem opdracht. Deze specifieke opdracht wordt O_EXCL genoemd en wordt gebruikt in combinatie met O_CREAT. Deze optie zorgt ervoor dat de open() actie niet uitgevoerd kan worden als het bestand al bestaat, maar deze controle of het bestand al bestaat wordt direct gekoppeld aan de creatie van het bestand.

Trouwens, de 'x' Gnu extensie voor het openen van de fopen() functie, vereist een exclusieve bestandsaanmaak, die een foutmelding genereert als het bestand al bestaat:

  FILE * fp;

  if ((fp = fopen (filename, "r+x")) == NULL) {
    perror ("Can't create the file.");
    exit (EXIT_FAILURE);
  }

Toegang tot de tijdelijke bestanden is ook belangrijk. Als je vertrouwelijke informatie in ee 644-bestand (lees/schrijfrechten voor de eigenaar, leesrechten voor de rest van de wereld) kan dat ook wat problemen opleveren:

	#include <sys/types.h>
	#include <sys/stat.h>

        mode_t umask(mode_t mask);

Normaal gesproken wordt een tijdelijk bestand in drie stappen gemaakt:

1. Unieke naam creatie (random) ;
2. Het openen van het bestand door middel van O_CREAT | O_EXCL, met de meest meest restrictieve rechten;
3. controle en correcte reactie op het resultaat op het moment dat het bestand geopend wordt (hetzij "retry" of "quit").

Hoe moet een tijdelijk bestand worden gemaakt?

      #include <stdio.h>

      char *tmpnam(char *s);
      char *tempnam(const char *dir, const char *prefix);

De functie accepteert eerst een NULL argument, daarna retourneert hij een statisch buffer adres. De inhoud zal worden verander tijdens de volgende aanroep tmpnam(NULL). Als het argument een al gealloceerde string is, dan wordt de naam hier gecopieerd, en dat vereist een string van tenminste L-tmpnam bytes. Wees voorzichtig met buffer-overflows! De man pagina vertelt meer over problemen wanneer de functie wordt gebruikt met een a NULL parameter, wanneer _POSIX_THREADS of _POSIX_THREAD_SAFE_FUNCTIONS zijn gedefinieerd.

De tempnam() functie geeft een pointer naar een string. De dir directory moet "passend" zijn (de man pagina omschrijft wat er bedoeld wordt met "passend"). Deze functie controleert of het bestand niet bestaat voordat het de naam retourneert. Echter, de man pagina's raden dit gebruik af, aangezien "passend" een varierende betekenis kan hebben, afhankelijk van de functie-implementatie. Hierbij melden we wat Genome aanraadt met betrekking tot gebruik:

  char *filename;
  int fd;

  do {
    filename = tempnam (NULL, "foo");
    fd = open (filename, O_CREAT | O_EXCL | O_TRUNC | O_RDWR, 0600);
    free (filename);
  } while (fd == -1);

       #include <stdio.h>

       FILE *tmpfile (void);

Met GlibC-2.1.3 is het onderstaande mogelijk. Deze functie gebruikt een mechanisme dat lijkt op tmpnam() om een bestandsnaam te genereren, en het opent de bijbehorende "descriptor". Het bestand wordt daarna verwijderd, maar Linux verwijdert het pas echt op het moment dat geen enkele bron het meer gebruikt, dat is het moment waarop de bestands "descriptor" wordt losgelaten met behulp van een close() systeem opdracht.

  FILE * fp_tmp;

  if ((fp_tmp = tmpfile()) == NULL) {
    fprintf (stderr, "Can't create a temporary file\n");
    exit (EXIT_FAILURE);
  }

  /* ... use of the temporary file ... */

  fclose (fp_tmp);  /* real deletion from the system */

De eenvoudigste gevallen hebben geen verandering aan bestandsnaam nodig, net zo min als overdracht aan een ander proces, maar alleen opslagruimte en de mogelijkheid om gegevens opnieuw uit te lezen uit de tijdelijke ruimte. Daarom hebben we de bestandsnaam van het tijdelijke bestand niet nodig, alleen de inhoud is van belang. De tmpfile() functie doet dit.

De man pagina's zeggen hier niets over, maar de "Secure-Programs-HOWTO" raadt dit niet aan. Volgens de auteur garanderen de specificaties niet de creatie van het bestand en hij is tot nu toe niet in staat geweest om iedere implementatie te controleren. Ondanks deze reserveringen, is dit de meest effectieve functie.

       #include <stdlib.h>

       char *mktemp(char *template);
       int mkstemp(char *template);

Volgens sommige versies is alleen de laatste "x" random, mktemp() vervangt de eerste vijf "x-en" met hetProcess ID (PID) ..., dit maakt de naam vrij makkelijk te raden. Sommige versies staan meer dan zes "x-en" toe.

mkstemp() is de aangeraden functie in de "Secure-Programs-HOWTO". Hieronder volgt de methode:

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>

 void failure(msg) {
  fprintf(stderr, "%s\n", msg);
  exit(1);
 }

/*
 * Maakt een tijdelijk bestand en laat het zien.
 * Deze routine verwijdert de bestandsnaam van het bestandssysteem, waardoor
 * het niet meer verschijnt op het moment dat de inhoud van de directory wordt opgevraagd.
 */
FILE *create_tempfile(char *temp_filename_pattern)
{
  int temp_fd;
  mode_t old_mode;
  FILE *temp_file;

  /* Maakt een bestand met beperkte toegang */
  old_mode = umask(077);
  temp_fd = mkstemp(temp_filename_pattern);
  (void) umask(old_mode);
  if (temp_fd == -1) {
    failure("Couldn't open temporary file");
  }
  if (!(temp_file = fdopen(temp_fd, "w+b"))) {
    failure("Couldn't create temporary file's file descriptor");
  }
  if (unlink(temp_filename_pattern) == -1) {
    failure("Couldn't unlink temporary file");
  }
  return temp_file;
}

Deze functies laten de problemen met betrekking tot abstractie en portabiliteit zien. In zoverre dat de standaard bibliotheekfuncties geacht worden bepaalde features te leveren (abstractie)...., maar de manier waarop deze geimplementeerd dienen te worden is afhankelijk van het systeem (portabiliteit). Bijvoorbeeld de tmpfile() functie die een tijdelijk bestand opent op verschillende manieren (sommige versies maken geen gebruik van O_EXCL). Of mkstemp() dat een variabel aantal "x-en" afhandelt, afhankelijk van de implementatie.  

Conclusie

We zijn door de meeste beveiligingsproblemen met betrekking tot "race conditions" aan bronnnen heen geraced. Onthoud dat je nooit mag aannemen dat twee achtereenvolgende operaties altijd direct na elkaar worden uitgevoerd door de processor, tenzij de kernel ze beheert. Als "race conditions" veiligheidslekken genereren, moet je niet het probleem oplossen door op andere bronnen te vertrouwen, zoals gedeelde variabelen tussen "threads" of gedeelde geheugensegmenten door gebruik te maken van shmget(). Selectiemechanismen (zoals bijvoorbeeld "semaphore") moeten worden gebruikt om moeilijk te vinden bugs te vermijden.

Links

• Secure-Programs-HOWTO by David A. Wheeler : www.linuxdoc.org/HOWTO/Secure-Programs-HOWTO/

Talkback voor dit artikel

2002-06-08, generated by lfparser version 2.28