Bonjour, Dixit JP Guillonneau, le 26/04/2019 : >Ces (anciennes) annonces de sécurité ont été publiées. Propositions. Pour RFD (dla-1413), c'est le fichier qui est réfléchi. https://www.securityweek.com/reflected-file-download-new-attack-vector-enables-file-downloads-without-upload >The attack is called Reflected File Download because the malicious >file is not actually hosted on the targeted website, but instead it's >reflected from it. « téléchargement de fichier par réflexion » ou « téléchargement de fichier réfléchi » (mais « réfléchir » sonne, à mes oreilles, plus proche de « penser » que de « miroir »). Baptiste
--- 0000075b.dla-1414.wml 2019-04-26 15:20:15.749825243 +0200 +++ ./0000075b.dla-1414-bj.wml 2019-04-26 15:26:12.681819825 +0200 @@ -17,7 +17,7 @@ <li><a href="https://security-tracker.debian.org/tracker/CVE-2017-17458";>CVE-2017-17458</a> -<p>In Mercurial avant 4.4.1, il est possible quâ??un répertoire malformé pour +<p>Dans Mercurial avant 4.4.1, il est possible quâ??un répertoire malformé pour lâ??occasion peut causer que des sous-dépôts exécutent du code arbitraire sous forme de script .git/hooks/post-update vérifié dans le dépôt. Lâ??utilisation typique de Mercurial empêche la construction de tels dépôts, mais ils peuvent @@ -25,11 +25,11 @@ <li><a href="https://security-tracker.debian.org/tracker/CVE-2018-1000132";>CVE-2018-1000132</a> -<p>Mercurial, version 4.5 et précédentes, contiennent une vulnérabilité de +<p>Mercurial, version 4.5 et précédentes, contient une vulnérabilité de contrôle dâ??accès incorrect (CWE-285) dans le serveur de protocole, qui pourrait aboutir à un accès à des données non autorisé. Cette attaque semble être exploitable à lâ??aide dâ??une connectivité réseau. Cette vulnérabilité semble -avoir été corrigée dans 4.5.1.</p> +avoir été corrigée dans la version 4.5.1.</p> <li>OVE-20180430-0001
--- 00000755.dla-1410.wml 2019-04-26 15:11:47.047533796 +0200 +++ ./00000755.dla-1410-bj.wml 2019-04-26 15:12:16.227206348 +0200 @@ -4,7 +4,7 @@ <p>Pysaml2, une implémentation de Python du Security Assertion Markup Language, acceptait nâ??importe quel mot de passe lorsquâ??exécuté avec les optimisations de Python activées. Cela permet à des attaquants de se connecter -sans connaître leur mot de passe.</p> +avec n'importe quel compte sans en connaître le mot de passe.</p> <p>Pour Debian 8 <q>Jessie</q>, ce problème a été corrigé dans la version 2.0.0-1+deb8u2.</p>
--- 00000765.dla-1418.wml 2019-04-26 15:23:09.463875859 +0200 +++ ./00000765.dla-1418-bj.wml 2019-04-26 15:26:11.637831539 +0200 @@ -21,15 +21,15 @@ lâ??algorithme, il advient que si le canal des données sur le CPU peut être contrôlé, les accès à la table de recherche sont suffisants pour divulguer des informations sur la clef utilisée. Il existait aussi une brèche dans AESEngine -quoique quâ??elle soit considérablement moindre. AESEngine a été modifié pour +quoiquâ??elle soit considérablement moindre. AESEngine a été modifié pour supprimer tout signe de brèche et est désormais la classe AES primaire pour le fournisseur de JCE de Bouncy Castle. Lâ??utilisation dâ??AESFastEngine est maintenant -seulement recommandée où cela semble plus appropriée.</p></li> +seulement recommandée où cela semble plus approprié.</p></li> <li><a href="https://security-tracker.debian.org/tracker/CVE-2016-1000341";>CVE-2016-1000341</a> <p>La génération de signatures DSA est vulnérable à des attaques temporelles. -Où les horodatages peuvent être observés de près lors de la génération de +Lorsque les horodatages peuvent être observés de près lors de la génération de signatures, le manque dâ??offuscation peut permettre à un attaquant dâ??obtenir des informations sur la valeur k de la signature et en définitive la valeur privée.</p></li> @@ -44,7 +44,7 @@ <p>Le générateur de paires de clefs DSA crée une clef privée faible sâ??il est utilisé avec les valeurs par défaut. Si le générateur de paires de clefs JCA -nâ??est initialisé explicitement avec des paramètres DSA, 1.55 et précédents +nâ??est pas initialisé explicitement avec des paramètres DSA, les versions 1.55 et précédentes génèrent une valeur privée en supposant une taille de clef de 1024 bits. Dans les publications précédentes, cela peut être réglé en passant explicitement des paramètres au générateur de paires de clefs.</p></li> @@ -61,7 +61,7 @@ <p>Dans le fournisseur de JCE de Bouncy Castle, la clef publique DH de lâ??autre partie nâ??est pas totalement validée. Cela peut causer des problèmes car des clefs non valables peuvent être utilisées pour révéler des détails sur la clef -privée de lâ??autre partie où Diffie-Hellman statique est utilisé. Comme dans +privée de lâ??autre partie où Diffie-Hellman statique est utilisé. Dans cette publication, les paramètres de clef sont vérifiés par calcul dâ??agrément.</p></li> </ul>
Attachment:
pgprU3nzPTqRk.pgp
Description: Signature digitale OpenPGP