Après nous avoir concocté le serveur FTP le plus troué de l'histoire (http://www.wu-ftpd.org/(...)), célèbre pour ses failles dans quasiment toutes les versions (2.4, 2.5, 2.6...), les développeurs de l'université Washingtown reviennent en force avec un buffer overflow dans leur serveur IMAP.
Il y a deux ans, après les nombreuses alertes concernant les versions successives de WU-FTPd, j'avais bani ce serveur et depuis, je ne jure plus que par ProFTPd (<pub>ProFTPd est génial !!!</pub>).
Va-t-il falloir en faire autant avec leur serveur IMAP ? Et pour Pine ? Eh oui, Pine est aussi un produit "WU"... mais bon, c'est seulement un client, pas un serveur (ouf !).
Pfff... Je sais bien que développer un serveur, c'est pas simple. Mais il existe des méthodes pour produire du code sûr : vérifier tous les codes de retour, les allocations mémoire, traiter les erreurs correctement... Oui, je sais, ça alourdit _énormément_ le code et en plus, ça suppose que le programme ait été conçu dès le début en respectant ces rêgles. Mais c'est faisable. De plus, puisque les machines sont de plus en plus rapides, on peut se permettre d'alourdir le code avec une floppée de tests dans tous les sens. En plus, dans le cas d'un serveur, c'est bien souvent le réseau qui ralentit tout.
# Encore un WU-gruyere !
Posté par Ludovic Boisseau . En réponse à la dépêche wu-imapd. Évalué à 10.
Il y a deux ans, après les nombreuses alertes concernant les versions successives de WU-FTPd, j'avais bani ce serveur et depuis, je ne jure plus que par ProFTPd (<pub>ProFTPd est génial !!!</pub>).
Va-t-il falloir en faire autant avec leur serveur IMAP ? Et pour Pine ? Eh oui, Pine est aussi un produit "WU"... mais bon, c'est seulement un client, pas un serveur (ouf !).
Pfff... Je sais bien que développer un serveur, c'est pas simple. Mais il existe des méthodes pour produire du code sûr : vérifier tous les codes de retour, les allocations mémoire, traiter les erreurs correctement... Oui, je sais, ça alourdit _énormément_ le code et en plus, ça suppose que le programme ait été conçu dès le début en respectant ces rêgles. Mais c'est faisable. De plus, puisque les machines sont de plus en plus rapides, on peut se permettre d'alourdir le code avec une floppée de tests dans tous les sens. En plus, dans le cas d'un serveur, c'est bien souvent le réseau qui ralentit tout.
Alors, à quand des serveurs sécurisés ?
Pour mémoire, le HOWTO relatif à la programmation sécurisée : http://www.dwheeler.com/secure-programs/(...)