... Un exemple de code vulnérable

Vous souvenez-vous de notre petit exercice dans le dernier numéro du Bulletin ?

 

Nous nous demandions si le code suivant avait été bien écrit :

 

 

1 /* Safely Exec program: drop privileges to user uid and group
2 * gid, and use chroot to restrict file system access to jail
3 * directory. Also, don’t allow program to run as a
4 * privileged user or group */
5 void ExecUid(int uid, int gid, char *jailDir, char *prog, char *const
argv[])
6 {
7 if (uid == 0 || gid == 0) {
8 FailExit(“ExecUid: root uid or gid not allowed”);
9 }
10
11 chroot(jailDir); /* restrict access to this dir */
12
13 setuid(uid); /* drop privs */
14 setgid(gid);
15
16 fprintf(LOGFILE, “Execvp of %s as uid=%d gid=%d\n”, prog, uid, gid);
17 fflush(LOGFILE);
18
19 execvp(prog, argv);
20}
(Avec l'aimable autorisation de Barton Miller, University of Wisconsin, Madison, US)

En effet, il n'était pas si bien écrit car il contenait au moins 13 défauts:

1. Ligne 1: spécifications incomplètes: tourne-t-il des commandes *arbitraires* ou juste quelques unes choisies ? Qui vérifie les erreurs ? La fonction ou l'appelant ? Fonctionne-t-il avec des prisons chroot *arbitraires* ? Qu'en est-il de la sûreté des threads ? Est-ce prévu pour s'exécuter dans un environnement multithread ?
2. Ligne 5: Selon la plateforme, il peut y avoir des problèmes liés aux nombres entiers.
3. Ligne 5: Pas d'assainissement de "jailDir". Par exemple "/" ne fera rien.
4. Ligne 11: Pas de vérifications des erreurs sur "chroot". chroot ("lkjhkjlhkljh") ou chroot (NULL) permettrait de contourner la prison.
5. Ligne 11: "chdir (jailDir)" manquant avant le chroot, ou chroot ("/") après.
6. Ligne 11: Pas de vérifications des erreurs.
7. Lignes 13/14: setuid & setgid s'exécutent dans le mauvais ordre.
8. Lignes 13/14: Pas de contrôles des erreurs, de sorte que l'attaquant peut choisir un nombre aléatoire pour les uid et gid et exécuter le programme en tant que root.
9. Ligne 16: LOGFILE est-il réellement ouvert ? Cela peut faire planter le programme, ou le rendre exploitable.
10. Ligne 19: Pas d'assainissement de prog, cela peut engendrer des déréférences du pointeur NULL, des plantages, etc, et rendre le code exploitable.
11. Ligne 19: Pas d'assainissement de environnement.
12. Ligne 19: Pas de gestion des erreurs: si execvp () retourne cela signifie qu'il y a une erreur qui doit être gérée. La spécification est faible dans ce cas.
13. Si le programme s'exécute dans un environnement multithread, l'assainissement devra faire des copies privées de jailDir, prog et argv[] et effectuer les vérifications sur eux.

 

Les gagnants des trois merveilleux livres sur la sécurité des logiciels sont Bertrand Lefort (BE/OP), Paolo Torelli (externe) et Remi Mommsen (CMS). Félicitations!!!

Vous pensez que ce n'est pas facile? C'est vrai --- et c'est l'avantage de tout attaquant. Il a juste à trouver quelques défauts pour exploiter ce code et prendre le contrôle du serveur correspondant. Ainsi, s'il vous plaît, veuillez vérifier les règles de base pour une bonne programmation ainsi que les livres essentiels sur le développement logiciel dans la section pour les développeurs de logiciels sur notre page web de sécurité. En outre, vous pouvez aussi tester facilement vos logiciels vous-même. Vérifiez soigneusement les avertissements de votre compilateur et utilisez un des analyseurs statiques de code que nous suggérons. De plus, les formations techniques HR fournissent des excellents cours sur la programmation sécurisée en Java, C++, Python, Perl et langages web. Les prochains cours pratiques, d'une journée, sont sur la sécurisation de PHP, Java et les applications web les 27, 28 et 29 septembre (respectivement) ainsi que sur  la programmation sécurisée en Python (28 octobre). Il y a encore des places disponibles !

Enfin, n'hésitez pas à contacter Computer.Security@cern.ch si vous préférez un examen externe de votre logiciel !

Bien sûr, si vous avez des questions, suggestions ou commentaires, s'il vous plaît contactez Computer.Security@cern.ch ou visitez notre page web http://cern.ch/security.

par Computer Security Team