Cette version contient quelques corrections sur la 7.4.7, dont des
correctifs sur des failles de sécurité.
E.43.1. Migration vers la version 7.4.8
Une sauvegarde/restauration n'est pas requise pour ceux utilisant
une version 7.4.X. Néanmoins, c'est une façon possible de gérer
deux problèmes de sécurité significatifs, qui ont été trouvé dans
le contenu initial des catalogues systèmes des versions 7.4.X. Une
séquence sauvegarde/initdb/restauration utilisant le initdb de la
7.4.8 corrigera automatiquement ces problèmes.
Le problème de sécurité le plus important est que les fonctions de
conversion du codage des ensembles de caractères peuvent être
appelées à partir de commandes SQL par des utilisateurs non
pribilégiés alors que les fonctions n'ont pas été conçues pour un
tel usage et ne sont pas sécurisées contre des choix rusés des
arguments. Le correctif implique de modifier la liste déclarée des
arguments de ces fonctions pour qu'elles ne soient plus appelées à
partir des commandes SQL. (Ceci n'affecte pas leur utilisation
normale par la machinerie de conversion du codage.)
Le problème le moins important est que le module contrib/tsearch2 crée plusieurs fonctions déclarant
par erreur renvoyées internal alors
qu'elles n'acceptent pas les arguments internal. Ceci casse la sûreté des types pour toutes
les fonctions utilisant des arguments internal.
Il est fortement recommandé que toutes les installations corrigent
ces erreurs, soit par un initdb soit en suivant les procédures de
réparation données ci-dessous. Les erreurs permettent au moins à
des utilisateurs non privilégiés de la base de données d'arrêter
brutalement leur processus serveur et pourraient permettre à des
utilisateurs non privilégiés de gagner les privilèges d'un
superutilisateur.
Si vous souhaitez ne pas lancer d'initdb, exécutez la procédure
suivante à la place en tant que superutilisateur de la base de
données :
BEGIN;
UPDATE pg_proc SET proargtypes[3] = 'internal'::regtype
WHERE pronamespace = 11 AND pronargs = 5
AND proargtypes[2] = 'cstring'::regtype;
-- La commande devrait rapporter qu'elle a mis à jour 90 lignes ;
-- si ce n'est pas le cas, annulez (rollback) et investiguez au lieu de valider !
COMMIT;
Ensuite, si vous avez installé contrib/tsearch2, faites
BEGIN;
UPDATE pg_proc SET proargtypes[0] = 'internal'::regtype
WHERE oid IN (
'dex_init(text)'::regprocedure,
'snb_en_init(text)'::regprocedure,
'snb_ru_init(text)'::regprocedure,
'spell_init(text)'::regprocedure,
'syn_init(text)'::regprocedure
);
-- La commande devrait rapporter qu'elle a mis à jour 90 lignes ;
-- si ce n'est pas le cas, annulez (rollback) et investiguez au lieu de valider !
COMMIT;
Si cette commande échoue avec un message comme « function "dex_init(text)" does not exist »,
alors soit tsearch2 n'est pas installé
dans cette base de données, soit vous l'avez déjà mise à jour.
Les procédures ci-dessus doivent être exécutées pour
chaque
base de données d'une
installation, ceci incluant template1 et
devant idéalement inclure aussi template0.
Si vous ne corrigez pas les bases de données modèles, alors toute
base de données créée par la suite contiendra les mêmes erreurs.
template1 peut être corrigé de la même
façon que les autres bases de données alors que template0 requiert des étapes supplémentaires. Tout
d'abord, à partir de n'importe quel base de données
UPDATE pg_database SET datallowconn = true WHERE datname = 'template0';
Ensuite, connectez-vous à template0 et
effectuez les opérations de réparation. Faites
-- gelez de nouveau template0:
VACUUM FREEZE;
-- et protégez-contre toute nouvelle modification :
UPDATE pg_database SET datallowconn = false WHERE datname = 'template0';
![[Note]](images/note.png)
Version 7.4.9
