2006-05-23
Cette version contient quelques corrections de la 8.0.7 incluant des correctifs pour des problèmes de sécurité extrêmement sérieux. Pour plus d'informations sur les nouvelles fonctionnalités de la version majeure 8.0, voir Section E.147, « Version 8.0 ».
Une sauvegarde/restauration n'est pas requise pour ceux utilisant une version 8.0.X. Néanmoins, si vous mettez à jour à partir d'une version antérieure à la 8.0.6, voir les notes de sortie de la 8.0.6.
Assurer une sécurité complète contre les attaques par injection SQL décrites dans CVE-2006-2313 et CVE-2006-2314 peuvent demander des modifications dans le code de l'application. Si vous avez des applications embarquant des chaînes non sûres dans des commandes SQL, vous devriez les examiner aussi rapidement que possible pour vous assurer qu'elles utilisent les techniques d'échappement recommandées. Dans la plupart des cas, les applications devraient utiliser des sous-routines fournies par des bibliothèques ou des pilotes (comme PQescapeStringConn() de libpq) pour réaliser l'échappement des chaînes plutôt que de se fier à un code ad hoc.
Modification du serveur pour qu'il rejette les caractères multi-octets mal codés dans tous les cas (Tatsuo, Tom)
Bien que PostgreSQL™ va dans cette direction depuis un certain temps, les vérifications sont maintenant appliquées uniformément à tous les codages et toutes les entrées de texte. Ce sont maintenant des erreurs, et non plus des messages d'avertissement. Ce changement sert à se défendre contre les attaques à base d'injection SQL du type décrit dans CVE-2006-2313.
Rejette des utilisations non sûres de \' dans les chaînes
En tant que défense côté serveur contre les attaques de type injection SQL décrit dans CVE-2006-2314, le serveur accepte maintenant seulement '' et plus \' comme représentation d'un guillemet simple ASCII dans des chaînes SQL. Par défaut, \' est rejetté seulement quand client_encoding est configuré avec un codage client seul (SJIS, BIG5, GBK, GB18030 ou UHC), qui est le scénario dans lequel l'injection SQL est possible. Un nouveau paramètre de configuration backslash_quote est disponible pour ajuster ce comportement si nécessaire. Notez qu'une sécurité complète contre CVE-2006-2314 pourrait nécessiter des modifications du côté client ; le but de backslash_quote est en partie de rendre évident que les clients non sécurisés sont non sécurisés.
Modification des routines d'échappement de texte de libpq pour le rendre conscient des considérations de codage
Ceci corrige les applications utilisant libpq pour les problèmes de sécurité décrits dans CVE-2006-2313 et CVE-2006-2314. Les applications qui utilisent les connections concurrentes multiples de PostgreSQL™ devraient migrer vers PQescapeStringConn() et PQescapeByteaConn() pour s'assurer que l'échappement est réalisé correctement pour les paramétrages utilisés dans chaque connexion de base de données. Les applications qui font des échappements de chaînes « à la main » devraient être modifiées pour se fier à aux routines de la bibliothèques à la place.
Correction de quelques fonctions de conversion de codage
win1251_to_iso, alt_to_iso, euc_tw_to_big5, euc_tw_to_mic, mic_to_euc_tw étaient toutes cassées à différents niveaux.
Nettoyage des utilisations restantes et parasites de \' dans les chaînes (Bruce, Jan)
Correction d'un bogue qui a quelque fois empêché des parcours d'index OR de ramener les lignes adéquates
Correction d'un replay WAL pour le cas où un index btree a été tronqué
Correction de SIMILAR TO pour les modèles impliquant | (Tom)
Correction de SELECT INTO et CREATE TABLE AS pour créer des tables dans le tablespace par défaut, et non pas dans le répertoire base (Kris Jurka)
Correction du serveur pour qu'il utilise les paramètres personnalisés DH SSL correctement (Michael Fuhr)
Correction de Bonjour pour les Intel Macs (Ashley Clark)
Correction de quelques pertes mémoires mineures
Correction d'un problème pour la demande du mot de passe sur certains systèmes Win32 (Robert Kinberg)