Un seul fopen introduit-il une vulnérabilité TOCTOU?
Je corrige actuellement le pilote sous Linux. Klokwork a dit que le code comme:
file = fopen(fileName, "w+"); // w+,r,a and any mix of those is used here
if (file != NULL) { /* do things*/ }
else { /* throw error */ }
fclose(file);
peut se terminer par une vulnérabilité de type Time-of-check à time-of-use.
Cependant, pour autant que je le lise, il faut faire quelque chose comme if(access()) avant fopen pour y arriver.
Et il y a une question: cet exemple de code que je montre a-t-il un point faible? ou je n'ai pas besoin de m'en soucier?
Un appel à fopen n'est pas en soi une vulnérabilité TOCTOU. Par définition, TOCTOU implique deux opérations: une "vérification" et une "utilisation".
Un exemple courant de vulnérabilité TOCTOU consiste à vérifier les autorisations d'accès avec access avant d'ouvrir un fichier. C'est un bogue (condition de concurrence critique) car les autorisations peuvent changer entre la vérification et l'ouverture, et c'est généralement une vulnérabilité car les autorisations de fichiers sont importantes pour la sécurité.
L'appel système access est très suspect car il n'y a pas beaucoup de façons de l'utiliser qui n'introduisent pas de TOCTOU. L'appel fopen en lui-même n'est pas particulièrement suspect car il existe de nombreuses façons de l'utiliser en toute sécurité. Cependant, cela ne signifie pas que access est le seul moyen de créer un TOCTOU avec fopen.
Un exemple de condition de concurrence critique qui peut se produire lors de l'ouverture de fichiers est si vous avez obtenu le nom de fichier à partir d'une source externe et que vous faites des hypothèses sur ce nom. Par exemple, si vous générez l'argument sur fopen en concaténant un nom de répertoire avec un nom de fichier et que vous avez effectué quelques vérifications sur le répertoire, il s'agit également d'une vulnérabilité TOCTOU. Les vérifications sur le répertoire peuvent ne plus être valides au moment où vous utilisez le répertoire pour ouvrir un fichier. C'est pourquoi Linux a l'appel système openat: vous pouvez donc appeler opendir sur un répertoire, effectuer des vérifications sur le répertoire, puis appeler openat pour ouvrir un fichier dans ce répertoire ( alors que open avec des noms concaténés ouvrirait un fichier dans un répertoire qui maintenant a ce nom, mais peut ne pas être celui que vous avez coché).
Alors oui, vous devez vous en soucier. Votre code peut ou non présenter une vulnérabilité. Dans mon expérience très limitée, Klocwork a beaucoup de faux positifs, mais tout n'est pas un faux positif. Commencez par lire attentivement le message complet. Examinez attentivement votre code, avec des objectifs de sécurité écrits, et suivez comment ces objectifs de sécurité sont atteints (ou non). Il n'y a pas de miracle: écrire du code correct et sécurisé est plus difficile que d'appliquer simplement une liste de contrôle.