FAQ sur la mise à jour de sécurité du 4 avril 2013
Bien que cette FAQ couvre la mise à jour du 4 avril 2013 en général, la majorité de son contenu se focalise sur la faille majeure de sécurité, corrigée dans cette version. La faille a pour identifiant CVE-2013-1899.
Existe-t-il des exploitations connues et disponibles de cette vulnérabilité ?
Il n'existe aucune exploitation connue au moment de la sortie du correctif.
Qui est tout particulièrement vulnérable ?
Tout système permettant un accès non restreint à un port réseau PostgreSQL, comme les utilisateurs de PostgreSQL sur un système cloud public, est vulnérable. Les utilisateurs dont les serveurs PostgreSQL ne sont accessibles que via des réseaux internes protégés ou qui ont des pare-feux ou des restrictions de leur accès réseau, sont moins vulnérables.
Une bonne règle de sécurité pour les bases de données : ne pas permettre l'accès au port du serveur de bases de données à partir de réseaux non sécurisées, sauf si cela est absolument nécessaire. Ceci est valable aussi pour les autres systèmes de bases de données.
Quelle est la nature de la vulnérabilité ?
La faille autorise les utilisateurs à utiliser une option en ligne de commande pour une connexion PostgreSQL, utilisée normalement pour le mode de restauration mono-utilisateur alors que PostgreSQL fonctionne en mode normal, multi-utilisateurs. Ceci peut être utilisé pour endommager le serveur.
Quelles exploitations potentielles sont permises par cette vulnérabilité ?
- Déni de service permanent : un attaquant non autorisé peut utiliser cette vulnérabilité pour ajouter des messages d'erreur PostgreSQL aux fichiers cibles dans le répertoire des données de PostgreSQL. Les fichiers corrompus de cette façon peuvent causer un arrêt brutal du serveur, qui refusera de redémarrer. Le serveur de bases de données peut être corrigé, soit en éditant les fichiers et en supprimant le texte inutile, soit en restaurant une sauvegarde.
- Escalade des droits pour la configuration : dans le cas où un attaquant a un droit légitime à se connecter sur le serveur de bases de données et que le nom de l'utilisateur et celui de la base sont identiques (par exemple un utilisateur web sur une base web), alors cette vulnérabilité peut être utilisée pour configurer temporairement une variable avec les droits d'un superutilisateur.
- Exécution de code arbitraire : si l'attaquant rencontre toutes les qualifications et a la possibilité de sauvegarder des fichiers sur le système de fichiers (même dans le répertoire tmp), alors il peut utiliser la vulnérabilité pour charger et exécuter du code C arbitraire. SELinux empêche ce type spécifique d'exploitation.
Quelles versions majeures de PostgreSQL sont affectées ?
Versions 9.0, 9.1 et 9.2.
Les utilisateurs de version 8.4 ne sont pas affectés. Les utilisateurs des versions 8.3 et antérieures ne sont pas affectées par cette vulnérabilité mais sont concernées par toutes les vulnérabilités découvertes depuis que ces versions ne sont plus maintenues.
Comment les utilisateurs peuvent-ils se protéger eux-même ?
- Téléchargez la mise à jour et installez-la sur chaque serveur dès que possible
- Assurez-vous que PostgreSQL n'accepte pas de connexions provenant de réseaux non sécurisés
- Auditez les utilisateurs des bases pour vous assurer que leur connexion nécessite une authentification et que les utilisateurs qui existent sont légitimes et utilisés
L'utilisation de système de sécurité avancé comme SELinux avec l'extension SEPostgres de PostgreSQL diminue, voire élimine, l'exposition et les dommages potentiels dus aux vulnérabilités de PostgreSQL.
Qui a eu accès à l'information sur cette vulnérabilité ?
La vulnérabilité a été tout d'abord donnée à l'équipe de sécurité de PostgreSQL.
Le PostgreSQL Global Development Group (PGDG) a, depuis plusieurs années, une politique lui permettant de donner accès à cette information et au correctif en premier lieu aux constructeurs de paquets binaires pour PostgreSQL (tels que les RPM et les installeurs Windows), pour que ces paquets soient disponibles lors de la sortie officielle. Ceci est vrai pour les versions mineures et majeures. Étant donné la prévalence de PostgreSQL-as-a-Service (PGaaS) comme mécanisme de distribution, nous avons revu cette politique pour gérer le cas des fournisseurs de solutions cloud. La nouvelle politique est toujours en rédaction et devrait bientôt être disponible.
Quand a été découvert cette vulnérabilité ?
Cette vulnérabilité a été rapportée à l'équipe de sécurité du PostgreSQL Global Development Group (PGDG) le 12 mars 2013.
Nous avons rempli la fiche CVE, avec l'aide de l'équipe de sécurité de Red Hat, le 27 mars.
Qui a découvert la vulnérabilité ?
Mitsumasa Kondo et Kyotaro Horiguchi du NTT Open Source Software Center lors d'un audit de sécurité. NTT est un contributeur PostgreSQL de long terme.
Comment a été rapportée cette vulnérabilité ?
Kondo-san et Horiguchi-san ont envoyé un email à security@postgresql.org.
Comme indiqué par TechCrunch et Hacker News, certaines entités incluant le fournisseur de plate-forme cloud Heroku ont eu un accès rapide à cette information et au correctif.
Pourquoi cela est-il arrivé ?
Heroku a eu accès au source corrigeant la vulnérabilité en même temps que les autres constructeurs de paquets. Comme Heroku était tout particulièrement vulnérable, la Core Team de PostgreSQL a travaillé avec eux pour sécuriser leur infrastructure et utiliser leur déploiement comme test des correctifs de sécurité, pour vérifier que la mise à jour ne cassait aucune fonctionnalité applicative. Heroku travaille en étroite collaboration avec les développeurs de la communauté et teste des fonctionnalités expérimentales dans leur service PostgreSQL.
Qui a eu accès au code avant la sortie officielle ?
Deux équipes communiquent sur des listes privées gérées par l'infrastructure PGDG. Les deux équipes ont accès au code source avant la sortie de tout paquet pour analyser le correctif de sécurité, puis pour créer les paquets des binaires PostgreSQL. Il s'agit de l'équipe de sécurité et de l'équipe des constructeurs de paquets. Dans les deux cas, ces groupes ont eu un accès rapide pour participer à la correction de la vulnérabilité.
Comment des utilisateurs ayant de gros déploiements et des applications très sensibles peuvent-ils obtenir un accès rapide aux informations de sécurité ?
Actuellement, le projet PostgreSQL ne fournit pas d'informations ou de code en avance de phase aux utilisateurs qui ne sont pas directement impliqués dans la correction des failles de sécurité ou dans la construction de paquets PostgreSQL pour d'autres utilisateurs. Il serait possible dans le futur que nous offrions de tels accès, mais nous n'en sommes pas encore capables.
Rendre le dépôt des sources inaccessible pendant le travail sur le correctif était-il une bonne décision ?
Étant donné la sévérité de la vulnérabilité, la Core Team de PostgreSQL a évalué le risque posé par la mise à disposition du code source avant les paquets binaires. Le risque était trop important.
La procédure normale pour partager une information sur les versions de sécurité est d'envoyer une annonce sur la liste de discussion des développeurs, pgsql-hackers@postgresql.org, une semaine avant la nouvelle version. Tom Lane l'a fait. Ensuite, à cause de la sévérité de la vulnérabilité, nous avons aussi envoyé une annonce sur pgsql-announce@postgresql.org et sur notre flux RSS pour les nouvelles. Nous l'avons fait pour que les administrateurs de bases de données aient suffisamment de temps pour planifier une fenêtre de maintenance pour la mise à jour.
La réalisation des annonces et de la version était dépendante de la disponibilité des volontaires œuvrant à la construction des paquets et à celle des gestionnaires de versions.
Comment le projet PostgreSQL est-il organisé ?
Le PostgreSQL Global Development Group (PGDG) est une organisation globale gérée par des volontaires. Nous avons une équipe principale (la Core Team) composée de six personnes, un certain nombre de contributeurs majeurs et plusieurs listes de discussion qui sont la portion centralisée de notre communauté. Voir ici pour les détails sur les contributeurs.
Comment sont ajoutés de nouveaux membres à l'équipe de sécurité et à l'équipe des constructeurs de paquets ?
L'appartenance à ces deux groupes est gérée par la Core Team.
À quelle fréquence trouve-t-on des vulnérabilités dans PostgreSQL ?
Nous avons entre zéro et sept problèmes mineurs de sécurité chaque année. C'est le premier problème de cette échelle depuis 2006 (un problème sur l'encodage des séquences d'échappement qui a aussi affecté d'autres systèmes de bases de données, dont MySQL).
Comment a été introduite la vulnérabilité ?
Il s'agit d'un effet de bord dû à une ré-écriture d'une portion de code afin d'optimiser les temps de connexion à un serveur PostgreSQL et de le rendre plus maintenable.
Qui découvre les vulnérabilités dans PostgreSQL ?
Nous avons la chance d'avoir un grand nombre d'ingénieurs en sécurité qui testent régulièrement PostgreSQL et indiquent les problèmes rencontrés de façon responsable pour qu'ils puissent être corrigés. Cela inclut :
- l'équipe qualité de sociétés comme NTT Open Source, EnterpriseDB et 2ndQuadrant
- les chercheurs en sécurité de l'agence de sécurité fédérale japonaise
- les chercheurs en sécurité de sociétés de sécurité comme Secunia
- le projet Coverity’s Scan
- et un grand nombre d'utilisateurs de la communauté qui nous rapportent des bugs.
Que contient en plus cette version ?
Elle corrige aussi quatre autres problèmes mineurs de sécurité, détaillés dans la page de sécurité et dans l'annonce de version. Elle inclut un certain nombre de correctifs de bugs, notamment deux problèmes de corruption potentielle de données avec la réplication binaire.