On Tue, 28 May 2002, Bruno Crochet wrote:
> Je re�ois souvent de la liste s�curit� Mandrake des messages ou il est
> question de "buffer overflow", du type de celui-ci:
Je compl�te ce qui a d�j� �t� dit par quelques exemples pratiques:
Premier cas:
on suppose un programme contenant une variable
bool�enne `is_normal_user', qui si fausse, donne les droits
super-utilisateur durant l'ex�cution.
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
/* BUGS
* - Weak error detection/recovery.
* - Unbounded array checking.
* EXPLOIT
% ./a.out truc 1234567890
0xbffffb1c 0xbffffb28
% ./a.out truc 12345678901
0xbffffb1c 0xbffffb28
% ./a.out truc 123456789012
0xbffffb1c 0xbffffb28
EXECUTION AVEC DROITS ANORMAUX.
*/
int main(int argc, char **argv) {
int is_normal_user = 1; /* by default be safe */
char buffer[10]; /* tampon */
printf("0x%x 0x%x\n", &buffer[0], &is_normal_user);
if (!strcmp("turlututu", argv[1])) {
is_normal_user = 0;
}
sprintf(buffer, "%s", argv[2]);
if (!is_normal_user) {
printf("EXECUTION AVEC DROITS ANORMAUX.\n");
}
return 0;
}
On remarquera que ce premier cas ne n�cessite pas d'ex�cution de code.
La plupart des s�curisations par marquage de pile non ex�cutable ne
peuvent donc rien faire contre cela. Il n�cessite par contre une bonne
connaissance du code ainsi que des conditions optimales pour �tre
exploit�. Dans notre cas l'exploitation se fait via la stack, mais
on se rend bien compte que cela peut se faire �galement par des
structures de donn�es en RAM.
Second cas:
Cas particulier du premier cas o� l'on �crase en fait une `variable'
sp�ciale (interne) qui correspond � l'adresse de retour de la
fonction. Dans ce cas on peut d�router l'ex�cution (p.ex. ex�cuter un
unlink(2) � la place d'un open(2), ou pire ex�cuter le buffer que
l'on a utilis� pour le d�bordement: dans ce dernier cas on peut
ex�cuter N'IMPORTE QUEL CODE dans le cas g�n�ral. Ce tout dernier cas
peut �tre souvent �vit� en rendant la pile non-ex�cutable. Mais il faut
se rendre compte que cela peut se contourner, tous les buffers n'�tant
pas allou�s sur la pile).
> En quoi un buffer overflow est-il dangereux?
Il permet � un attaquant, via des entr�es de donn�es sp�cialement con�ues
(via param�tres de ligne de commande y compris nom de programme, donn�es
dans une base de donn�es, param�tres d'un FORMulaire HTML, donn�es d'une
session TCP, etc) de prendre le contr�le de variables du programme, voire
du flux de contr�le du programme, voire m�me de faire ex�cuter n'importe
quel code d�sir� par l'attaquant avec les droits du programmes.
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question. Ouais, pour se d�sabonner aussi.
