Cyberduck: CVE-2021-44228

Le CD semble utiliser une très ancienne version (1.2.17) https://github.com/iterate-ch/cyberduck/blob/e4c2dfe5c1e5623a5bfc484ae3f4ae58a1e929f1/pom.xml#L198 qui présente d'autres problèmes de sécurité https://www.cvedetails. com/cve/CVE-2019-17571/

Comme dit, nous n'avons pas de dépendance pour Apache Log4j 2. De plus, en tant qu'application de bureau côté client, cela ne semble pas pertinent.

@dkocher Où cela a-t-il été discuté auparavant ? J'ai cherché mais je n'ai pas trouvé.
Le CD dépend de log4J 1, pas 2, mais 1 semble également être affecté https://twitter.com/nluedtke1/status/1469435658389561345
Même en tant qu'application côté client, vous vous connectez peut-être à un serveur contenant des fichiers avec des échappements $ que vous enregistrez et exécutez.

@dkocher log4j apparaît dans votre pom.xml - donc quelque chose semble l'utiliser ?

Je vois aussi un fichier de configuration pour cela - https://github.com/iterate-ch/cyberduck/blob/fa0aa0d5d7b07ec09a4c328b2c0cf9a56bf01c4d/core/src/main/resources/log4j.xml

Ainsi que des références à celui-ci dans votre code- https://github.com/iterate-ch/cyberduck/blob/745598c7f84e48b21d7b7b6679db926d5d6e98e4/core/src/main/java/ch/cyberduck/core/logging/LoggerPrintStream.java#L19

Il est logique de éventuellement s'éloigner/mettre à niveau de Log4j 1.x mais je ne vois aucune urgence immédiate dans cette mise à niveau de dépendance . Je ne vois pas que CVE-2019-17571 nous affecterait car, d'après ce que j'ai compris, cet usage devrait être explicitement configuré.

CVE-2019-17571 est lié aux versions log4j >= 1.2, <= 1.2.27. Dans le package Cyberduck, je trouve log4j-1.2.17. Pourquoi cela n'affecte-t-il pas Cyberduck, même si la version de log4j est affectée ?

Parce que cette vulnérabilité n'affecte que le Log4j SocketServer qui, lorsqu'il est utilisé pour se connecter de manière centralisée à partir de clients distants, peut exécuter du code arbitraire. Cyberduck ne fournit pas de cible de journalisation centrale et n'est donc pas affecté.

lors de l'écoute du trafic réseau non approuvé pour les données de journal

Étant donné que log4j 1 n'est plus pris en charge, les vulnérabilités ne sont pas suivies et nous devons supposer qu'il n'est pas sûr.

Étant donné que log4j 1 n'est plus pris en charge, les vulnérabilités ne sont pas suivies et nous devons supposer qu'il n'est pas sûr.

Log4j 1.x ne dispose pas de la fonctionnalité JNDI qui a causé CVE-2021-44228

Mais il peut avoir d'autres problèmes non documentés.

Mais il peut avoir d'autres problèmes non documentés.

Comme n'importe quel logiciel.

Les responsables de log4j documentent et résolvent uniquement les problèmes sur les versions prises en charge. Utiliser log4j 1, c'est comme utiliser Windows XP : vous ne savez même pas comment vous pourriez être attaqué.

Il existe déjà un certain nombre de (grandes) entreprises qui n'autorisent aucune ancienne bibliothèque log4j (vulnérable) sur les ordinateurs portables des employés. Sans une version appropriée de log4j, cyberduck ne fonctionne plus car la bibliothèque est automatiquement supprimée des appareils de l'entreprise.

Il existe déjà un certain nombre de (grandes) entreprises qui n'autorisent aucune ancienne bibliothèque log4j (vulnérable) sur les ordinateurs portables des employés. Sans une version appropriée de log4j, cyberduck ne fonctionne plus car la bibliothèque est automatiquement supprimée des appareils de l'entreprise.

J'ai ouvert #12706.