Sécurité des signaux sous Unix, cas de Sendmail

Date :11 Juillet 2005

Publication: Article

Afin de développer une application conforme aux contraintes de sécurité, un certain nombre de recommandations sont à prendre en compte lors de sa programmation. Cela permet de se prémunir contre les débordements de pile, les vulnérabilités de type " format string ", les attaques par lien symbolique, etc…

Un article publié dans BugTraq soulève une contrainte de sécurité relativement méconnue dans les environnements Unix, en rapport avec l’utilisation des signaux (primitives " signal ") dans les programmes. En effet, une mauvaise utilisation des signaux peut être source de vulnérabilités, ces vulnérabilités pouvant conduire à des compromissions locales et même distantes. Cet article s’appuie sur le cas concret du serveur de messagerie Sendmail, qui présente des vulnérabilités dans sa gestion des signaux.

Contrairement aux idées reçues, il est donc important d’avoir à l’esprit un certain nombre de règles afin de programmer de façon sécurisée tout en utilisant les signaux Unix .

Le problème se situe dans la fonction " handler " assignée aux signaux (i.e. la fonction qui sera exécutée sur réception du ou des signaux qui lui ont été affectés). Il faut que cette fonction contienne uniquement des opérations atomiques.

A cet effet, la plupart des systèmes Unix disposent d’un ensemble de fonctions garanties " signal-safe ". Malheureusement, seuls certains systèmes (comme OpenBSD ou Solaris) sont documentés précisément à ce sujet.

Par exemple, sous OpenBSD, des fonctions comme fork ou open sont " signal-safe ", et peuvent être utilisées dans un " handler ", alors que l’utilisation de malloc est à proscrire.

A l’aide de la vulnérabilité découverte dans Sendmail, on peut voir un scénario d’exploitation :

Dans le cas où un " handler " est rattaché à plusieurs signaux, si ce " handler " contient des appels à des fonctions non sûres, alors une corruption de la pile d’exécution du programme peut avoir lieu. Il faut pour cela que le programme reçoive un premier signal (qui déclenche l’exécution du " handler ", puis un second signal qui provoque une nouvelle exécution du " handler " alors que la précédente n’est pas terminée. Le " handler " n’étant pas programmé de manière réentrante, il peut y avoir corruption de mémoire. Dans le cas de Sendmail, la fonction incriminée est syslog. Cette fonction prenant en paramètre des données utilisateur, un attaquant peut écrire dans la pile du code arbitraire.

Les signaux sont bien sûr un mécanisme utilisable en local.

Notons cependant qu’en théorie, ce type d’attaque, typiquement local, peut aussi être réalisé à distance. En effet, il existe le signal SIGURG qui est généré via TCP/IP à travers le trafic OOB (Out Of Band). Un certain nombre de logiciels serveurs (notamment pour les services FTP, http et mail) peuvent être amenés à utiliser ce signal. Des compromissions distantes peuvent donc exister.

Conclusion

Ce type de vulnérabilité ne semble pas actuellement exploité, et sa mise en œuvre reste délicate, car dépendant du contexte d’exécution de la machine cible. Il ne faut cependant pas le négliger.

Les mesures à prendre pour s’immuniser contre ce type de problème sont :

  • Les " handlers " qui gèrent la réception des signaux doivent être les plus simples possible, et ne contenir que des appels à des fonctions garanties " signal-safe " (qu’elles soient réentrantes ou atomiques).

ou

  • Bloquer la réception des signaux lors d’opérations n’obéissant pas à la règle précédente dans un " handler ".

ou

  • Bloquer la réception des signaux dans un " handler ".

 

Informations supplémentaires :