RSS

Race Conditions

10 nov

O que é ?

Em palavras simples “Race Condition” é rotulado quando o código é uma condição não atômica ou seja thread-unsafe e não reentrante, uma condição de corrida é um comportamento anômalo causado pela dependência inesperada no tempo relativo de eventos, Race Condition pode ter vários contextos tais como em “threads”, “Time of check, time of use race condition”,”switch” em adição quando o desenvolvedor não trata todos os dados de entrada “stdin”, algum desses dados pode comprometer a integridade do sistema seja abrindo algum arquivo como “/etc/shadow“, fazendo disclosure de outros arquivos que você não gostaria, sim pode ter relação direta com a falha LFD(Local File Disclosure) na maioria dos casos comuns, mas condições de corrida estão além, imagina você manipular um arquivo temporário e criar um link simbólico para o local do qual gostaria, vou tentar passar um conceito básico neste post.
road_rash_-_1992_-_electronic_arts1
Vamos a um exemplo, tudo começa com uma má prática de permissão
ou acesso no file system com uso sem tratamento dos dados dos argumentos
passados para os syscalls exemplo open(),read(),chmod(),symlink(),unlink(),
lchown(),chown()
entre outras funções que envolve manipulação de permissões e
arquivos , “háha mais eu uso fopen()” rode um “strace” no executável do
seu programa que você terá uma surpresa o syscall open() estará la.
linguagens como Java,Perl,Ruby dependem da libC para rodar em unix
like fora as syscalls então não são imunes ao problema , irei mostrar
um ponto empírico;

cooler@lisperian:/etc$ LD_TRACE_LOADED_OBJECTS=1 jvm
linux-gate.so.1 => (0x0022a000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0x0093f000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0x00e12000)
libutil.so.1 => /lib/i386-linux-gnu/libutil.so.1 (0x00183000)
libssl.so.1.0.0 => /lib/i386-linux-gnu/libssl.so.1.0.0 (0x0018a000)
libcrypto.so.1.0.0 => /lib/i386-linux-gnu/libcrypto.so.1.0.0 (0x0031a000)
libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0x00110000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0x00c15000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0x00641000) --> aqui libC
/lib/ld-linux.so.2 (0x00b20000)

Relaxe normal a “jvm” do java depender de C ,poh DMR morreu ninguém falo nada
se fosse o James Gosling! hehehe…

Ao falar de “Race Conditions” no contexto de “threads”, temos duas formas condições não atômicas
e atômicas ,condições atômicas não são vulneráveis , mas as condições não atômicas
são vulneráveis são thread-unsafe e não reentrantes.

*O que é “não reentrante” ?

Não reentrante refere-se a qualidade duma subrotina de ser executada concorrentemente
de forma insegura, é exatamente o antônimo de reentrante que seria uma subrotina segura.

Ex:


 int madruga = 2;

 int foo()
 {
   madruga += 8;
   return madruga;
 }

 int gamma()
 {
   return ( ( foo() -4 ) << 2) ;
 }

Se duas thread executar uma função seja foo() ou gamma()
vai dar algum bug com atropelamento da variável madruga
dando um resultado inesperado…

* O que é Thread-unsafe ?

A thread fica insegura quando os dados de forma concorrentemente
são alterados por usar uma variável global ou por não usar Lock por
mutex , quando usamos fork() não precisamos nos preocupar, mas ao usar
pthread por exemplo deve-se ter controle seja com mutex ou com semáfaros.

Ex

// gcc -o code code.c -lpthread
#include <stdio.h>
#include <malloc.h>
#include <pthread.h>

int y=1;

void *foo(void * sum)
{
 y+=*(int *)sum;
 printf(" result: %d \n",y);
}

int main()
{
 int x=0,num_thread=20;
 void *pointer=&y;

 pthread_t * threads;
 threads = (pthread_t *) malloc(num_thread * sizeof (pthread_t));

  for(x = 0; x < num_thread; x++)
   if(pthread_create (&threads[x], NULL, foo, pointer) != 0)
    error ("pthread_create");

  for(x = 0; x < num_thread; x++)
   pthread_join (threads[x], NULL);

 free(threads);
 return 0;
}

veja que este código é executado sem nenhum controle dos dados
ficam de acordo com o acaso de uma entropia da concorrência das
threads…

vamos passar o valgrind usando a tool helgrind para analisar o programa

cooler@lisperian:~/race_condition$ valgrind --tool=helgrind ./thread
==4543== Helgrind, a thread error detector
==4543== Copyright (C) 2007-2010, and GNU GPL'd, by OpenWorks LLP et al.
==4543== Using Valgrind-3.6.1-Debian and LibVEX; rerun with -h for copyright info
==4543== Command: ./thread
==4543==
resultado 2
==4543== Thread #3 was created
==4543== at 0x413A0B8: clone (clone.S:111)
==4543==
==4543== Thread #2 was created
==4543== at 0x413A0B8: clone (clone.S:111)
==4543==
==4543== Possible data race during read of size 4 at 0x804a028 by thread #3
==4543== at 0x804855D: foo (in /home/cooler/info_leak/race_condition/thread)
==4543== by 0x4028F62: mythread_wrapper (hg_intercepts.c:221)
==4543== by 0x4052D30: start_thread (pthread_create.c:304)
==4543== by 0x413A0CD: clone (clone.S:130)
==4543== This conflicts with a previous write of size 4 by thread #2
==4543== at 0x8048566: foo (in /home/cooler/info_leak/race_condition/thread)
==4543== by 0x4028F62: mythread_wrapper (hg_intercepts.c:221)
==4543== by 0x4052D30: start_thread (pthread_create.c:304)
==4543== by 0x413A0CD: clone (clone.S:130)
==4543==
==4543== Possible data race during write of size 4 at 0x804a028 by thread #3
==4543== at 0x8048566: foo (in /home/cooler/info_leak/race_condition/thread)
==4543== by 0x4028F62: mythread_wrapper (hg_intercepts.c:221)
==4543== by 0x4052D30: start_thread (pthread_create.c:304)
==4543== by 0x413A0CD: clone (clone.S:130)
==4543== This conflicts with a previous write of size 4 by thread #2
==4543== at 0x8048566: foo (in /home/cooler/info_leak/race_condition/thread)
==4543== by 0x4028F62: mythread_wrapper (hg_intercepts.c:221)
==4543== by 0x4052D30: start_thread (pthread_create.c:304)
==4543== by 0x413A0CD: clone (clone.S:130)
==4543==
resultado 4
resultado 8
resultado 16
resultado 32
resultado 64
resultado 128
resultado 256
resultado 512
resultado 1024
resultado 2048
resultado 4096
resultado 8192
resultado 16384
resultado 32768
resultado 65536
resultado 131072
resultado 262144
resultado 524288
resultado 1048576
==4543==
==4543== For counts of detected and suppressed errors, rerun with: -v
==4543== Use --history-level=approx or =none to gain increased speed, at
==4543== the cost of reduced accuracy of conflicting-access information
==4543== ERROR SUMMARY: 38 errors from 2 contexts (suppressed: 715 from 32)

O próprio valgrind já disse tudo …

Quanto ao fopen(),open() fica uma dica de como fazer da forma segura:

https://www.securecoding.cert.org/confluence/display/seccode/FIO03-C.+Do+not+make+assumptions+about+fopen%28%29+and+file+creation

Lembrando sempre de validar close(),fclose() também…

https://www.securecoding.cert.org/confluence/display/seccode/FIO22-C.+Close+files+before+spawning+processes

 

* Veja alguns exploits

-Famoso XPL que se aproveita de um race condition “h00lyshit”

-Race condition no bzexe pode comprometer integridade de um sistema veja

e muitos outros…

Nos casos mais comuns é se aproveitar de um arquivo aberto para usar “symlink()”
para dar disclosure de um “/etc/shadow” por exemplo, muitos programadores cometem erros
em permissões ou em usar “open()”, a dica em arquivos é usar “flock()” .

Um obrigado ao meu brother “sigsegv“,que está presente no servidor irc.freenode.net
canal #c-br, Valeu pela dicas de race condition sigsegv 😉

Anúncios
 
1 comentário

Publicado por em novembro 10, 2011 em hacking, Linguagem C, segurança de sistemas

 

Uma resposta para “Race Conditions

  1. B0b0_d4_c0rt3

    novembro 10, 2011 at 2:16 pm

    Excelente !!!

    []’s
    B0b0_d4_c0rt3

     

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

 
%d blogueiros gostam disto: