Discussion :

[manticore]

Bonjour,

en lisant un livre sur le fuzzing, je suis tombé sur un problème intéressant de race condition :

Imaginons un programme utilisant le setuid linux. Il effectue une écriture dans un fichier avec un code ressemblant à celui-la :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
#include <stdio.h>
#include <string.h>
#include <sys/stat.h>
#include <unistd.h>
#include <sys/types.h>
 
int checkAccess(char* _filename)
{
	struct stat results;
	stat(_filename, &results);
 
	if (results.st_mode & S_IWUSR) return 1;
	else return 0;
}
 
int main(char argc, char* argv[])
{
	FILE* fp;
	char* filename = "leg_file.txt";
 
	pid_t pid = getpid(); 
	printf("PID %d\n", pid);
 
	while(1)
	{	
		if(checkAccess(filename) == 1)
		{
			printf("10 second for exploit\n");
			sleep(10);
			fp = fopen(filename, "a+");
			printf("New open\n");
			fwrite("a\n", 1, 2, fp);
			fclose(fp);
			printf("Now is close\n");
		}
	}
 
	return 1;
}

En exécutant ce logiciel, on remarque qu'il y a un laps de temps entre le check des droits et l'écriture dans le fichier..

On peut donc utiliser ce lap de temps pour remplacer le fichier légitime :
- leg_file.txt
par
- cp -s /etc/passwd leg_file.txt

Mon soucis est que je ne trouve aucune parade (en code uniquement) pour lutter contre cette race condition.

p.s. Evidemment le sleep est la pour simplifier l'exploit, mais on peut imaginer un bruteforce.

[ternel]

En théorie, ne serait-ce pas au système de fichier de bloquer les appels à fopen() sur des fichiers invalides?

[manticore]

En théorie, ne serait-ce pas au système de fichier de bloquer les appels à fopen() sur des fichiers invalides?

Dans ce cas , l'ouverture du fichier est valide (il y a le sticky bit) et on ouvre un fichier qui est possédé par root.

On peut régler/limiter le problème, en gérant efficacement les droits sur notre filesysteme :

- Selinux
- chdir
- user dédié
- ...

Mais c'est un exemple, imaginons que le système de fichier ne peut être modifié. Et que l'on doit régler le problème en C.

Par exemple existe-t-il un moyen de "locker" un fichier ?

[Metalman]

"locker" depuis un programme X pour que tous les autres ne puissent pas y accéder... ça signifie effets de bords... et hormis le FS, je ne pense pas qu'il existe autre chose pour bloquer un fichier...

[ternel]

Pas a ma connaissance. Si tu ne peux pas te fier au système, où va-t-on?

Cela dit, ton système de fichier sera modifié, puisque tu va y placer ton exécutable…

[Médinoc]

Je dirais tu commences par ouvrir le fichier, puis tu fais un stat() ou fstat() dessus...

[manticore]

Pas a ma connaissance. Si tu ne peux pas te fier au système, où va-t-on?

C'est surtout une question d'élévation de privilège, je te donne un accès user et tu peux monter en root à cause de ton application c'est pas très propre.

Ensuite, je ne vois pas où tu veux en venir avec « cp -s /etc/passwd leg_file.txt ». En faisant ceci, tu copies le fichier /etc/passwd dans le tien mais le fichier /etc/password original reste intact.

cp -s créer un lien symbolique je préfère cette forme à ln à cause du sens des opérateurs.

Cela dit, cela ne règle pas ton problème du tout : n'importe quel utilisateur pourra lui-aussi ouvrir ton fichier et écrire dedans MÊME si tu l'as ouvert. Donc, que cela se passe pendant le délai de grâce accordé à l'exploit ou pendant le déroulement du programme ne change rien.

En faite il faut checker que l'utilisateur qui lance le binaire aille les droits d'ouvrir le fichier par le fopen(). Car vu que le binaire est lancé avec le sticky bit lui aura les droits.

En faite pour faire correctement cette ouverture :

1. fopen()
2. Check si l'utilisateur qui lance le binaire peut écrire dans le fichier
3. Si ok -> écriture
4. Si non exception

Juste pour illustrer le problème si on ne check pas les droits.

1. fopen()
2. On supprime le fichier légitime et on le remplace par un lien symbolique sur /etc/passwd
3. fwrite() écrit dans /etc/passwd avec les droits root

Si on peut contrôler ce qui est écrit on peut s'ajouter un utilisateur root.

[Obsidian]

Par exemple existe-t-il un moyen de "locker" un fichier ?

Il existe des verrous fichiers sous UNIX (voir flock(), lockf() et fcntl() avec F_GETLK, F_SETLK et F_SETLKW) mais ceux-ci sont consultatifs par défaut. Il faut activer une option spéciale au montage du système de fichiers (sous Linux, voir Documentation/filesystems/mandatory-locking.txt dans les sources du noyau). En bref : c'est une fausse bonne idée.

Dans le cas qui te préoccupe, tu n'es absolument pas obligé de faire un test préalable avec stat() avant d'ouvrir ton fichier : tu peux faire un open() directement qui échouera avec le code d'erreur idoine si tu n'as pas les droits de le faire. Dans ce cas, l'atomicité est garantie. Tu peux même éventuellement faire un stat() après l'ouverture si tu as toujours besoin de connaître ces infos.

Cela dit, cela ne règle pas ton problème du tout : n'importe quel utilisateur pourra lui-aussi ouvrir ton fichier et écrire dedans MÊME si tu l'as ouvert. Donc, que cela se passe pendant le délai de grâce accordé à l'exploit ou pendant le déroulement du programme ne change rien.

Ensuite, je ne vois pas où tu veux en venir avec « cp -s /etc/passwd leg_file.txt ». En faisant ceci, tu copies le fichier /etc/passwd dans le tien mais le fichier /etc/password original reste intact.

Enfin, à titre indicatif, si tu remplaces l'entrée du fichier par un lien symbolique ou même si tu le supprimes pendant qu'il est utilisé, il ne se passe rien non plus. Le fichier initialement ouvert restera sur le disque tant qu'un programme au moins aura un handle valide dessus. Le système l'effacera automatiquement et définitivement dès lors que le dernier programme à l'avoir ouvert le refermera et qu'il n'y aura plus de référence existante sur le volume qui le contient (autrement dit : plus de liens durs).

[gangsoleil]

Bonjour,

Je ne vois pas non plus le probleme...