Re: [RFR] wml://lts/security/2020/dla-22{78,79 }.wml
Bonjour,
Le 14/07/2020 à 12:31, JP Guillonneau a écrit :
> Merci d’avance pour vos relectures.
>
suggestions,
amicalement,
bubu
--- dla-2278.wml 2020-07-14 14:27:10.491686138 +0200
+++ dla-2278.relu.wml 2020-07-14 14:28:37.622434621 +0200
@@ -2,8 +2,8 @@
<define-tag description>Mise à jour de sécurité pour LTS</define-tag>
<define-tag moreinfo>
<p>Il a été découvert que Squid, un serveur mandataire et de cache de haute
-performance pour les clients web, était affecté de plusieurs vulnérabilité de
-sécurité. À cause d’une mauvaise validation d’entrée et de gestion de requête
+performance pour les clients web, était affecté de plusieurs vulnérabilités de
+sécurité. À cause d’une mauvaise validation d’entrée et de gestion de requêtes
d’URL, il était possible de contourner les restrictions d’accès à des serveurs
HTTP limités et de provoquer un déni de service.</p>
--- dla-2279.wml 2020-07-14 14:22:20.846739269 +0200
+++ dla-2279.relu.wml 2020-07-14 14:25:00.335618000 +0200
@@ -9,11 +9,11 @@
<li><a href="https://security-tracker.debian.org/tracker/CVE-2020-9484";>CVE-2020-9484</a>
-<p>Lors de l’utilisation d’Apache Tomcat, et a) un attaquant pouvait contrôler le
+<p>Lors de l’utilisation d’Apache Tomcat, et que : a) un attaquant pouvait contrôler le
contenu et le nom d’un fichier sur le serveur, b) le serveur était configuré pour
utiliser le PersistenceManager avec un FileStore, c) le PersistenceManager était
configuré avec sessionAttributeValueClassNameFilter="null" (par défaut à moins
-qu’un SecurityManager était utilisé) ou un filtre suffisamment laxiste pour
+qu’un SecurityManager ne soit utilisé) ou un filtre suffisamment laxiste pour
permettre à l’attaquant de fournir un objet à désérialiser et d) l’attaquant
connaissait un chemin relatif de fichier vers l’emplacement de stockage utilisé
par FileStore pour le fichier dont l’attaquant avait le contrôle, alors, à l’aide
Reply to: