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.
Il n'existe aucune exploitation connue au moment de la sortie du correctif.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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é.
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.
É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.
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.
L'appartenance à ces deux groupes est gérée par la Core Team.
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).
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.
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 :
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.