Theo de Raadt a proposé d'inclure un nouveau mécanisme dans OpenBSD pour réduire la surface d'attaque, mis en œuvre via l'extension des capacités du système d'appel openat. Des correctifs avec la réalisation de drapeaux supplémentaires pour openat et open, limitant la possibilité de navigation vers les répertoires supérieurs à travers « /.. » et l'accès par des chemins absolus, ont été préparés pour le noyau, libc, ainsi que pour certaines applications du système de base. Les changements ne sont pas encore inclus dans OpenBSD-current et sont en cours de discussion parmi les développeurs.
La famille des appels système openat(2) fonctionne comme un équivalent de open(2) à l'exception du fait que si le paramètre « path » spécifie un chemin relatif, le fichier ouvert est déterminé par rapport au répertoire associé au descripteur de fichier « fd », et non par rapport au répertoire de travail actuel. Si un chemin absolu est transmis à openat, par exemple : int dirfd = open("/tmp", O_RDONLY | O_DIRECTORY); int hfd = openat(dirfd, "/etc/hosts", O_RDONLY);
la fonction openat() ignorera « dirfd » et, par conséquent, le chemin absolu sera traité de la manière habituelle.
Ainsi, remplacer open() par openat() n'améliore pas en soi la sécurité du programme. Un tel appel peut accélérer l'analyse du chemin, mais ne limite pas l'accès au système de fichiers. Les drapeaux interdisant les chemins absolus (comme RESOLVE_BENEATH et/ou RESOLVE_IN_ROOT pour openat2 sous Linux) ne garantissent pas de protection : le programmeur doit les ajouter à tous les appels appropriés, et lors de la prise de contrôle du processus, un attaquant peut tirer parti d'autres chemins pour ouvrir des fichiers.
Lors du développement de l'outil openrsync, Theo a eu besoin de restreindre ses capacités à traverser le système de fichiers, mais il n'a pas été possible de le faire avec les fonctions unveil() et pledge(). L'idée d'un mécanisme similaire à openat(), mais avec des propriétés de sécurité supplémentaires complétant pledge/unveil ou même fonctionnant en leur absence, est donc née.
L'idée principale est d'intégrer les restrictions directement dans le descripteur de répertoire. Pour cela, un drapeau F_BELOW est proposé, pouvant être défini via fcntl(), ou le drapeau O_BELOW pour open(). Un descripteur « dirfd » ainsi restreint ne permettra que les navigations descendantes dans l'arborescence des répertoires : les appels openat() avec un chemin absolu ou des remontées par « .. » échoueront avec l'erreur ENOENT. En cas d'attaque conduisant à l'exécution de code, la table des descripteurs de fichiers du processus contiendra des « dirfd » moins fonctionnels, ce qui limitera la surface d'attaque.
Source : opennet.ru
