Aller au contenu

Audits lus en détail — Briar, Threema et Delta Chat

Registre de preuves — Phase 2

Ce dossier est une pièce de recherche datée. La conclusion canonique est celle du rapport final 1.0. Les synthèses antérieures et renvois à la Phase 3 restent historiques. UNKNOWN reste UNKNOWN.

Briar — Cure53, mars 2017

  • FACT — organisme/date/durée : Cure53, mission terminée en mars 2017, six testeurs, 13 jours. Rapport du 20 mars 2017. Méthode white-box avec source Android et APKs de debug fournis. Rapport complet.
  • Version/commit : rapport dit app à un stade très précoce; numéro de release ou commit exact non établi dans le PDF consulté.
  • Scope : app Android et code source; revue de protocoles BQP, BSP et BTP et cryptographie. Trois jours dédiés à l’analyse crypto; le code crypto a reçu deux jours de revue; des spécifications BSP/BTP ont d’abord été jugées trop peu détaillées, puis « appropriées » après échanges. Pas d’app iOS ni d’infrastructure serveur à auditer, Briar n’ayant pas le serveur central classique.
  • Findings : 12 au total, six vulnérabilités et six problèmes informatifs. Vulnérabilités : High — fuite DNS via import RSS; Medium — capture d’écran faute de FLAG_SECURE, tapjacking pouvant configurer/déclencher Panic et effacer les données, activités exportées/interruption, PendingIntent potentiellement détournable; Low — déconnexion arbitraire par PanicResponderActivity. Informational — fuites possibles dans logcat/debuggable, crash par intent, DoS de padding, contrôle de force du mot de passe et combinaison inutile de deux CSPRNG.
  • Recommandations/remédiation : restrictions de capture écran, contrôle des overlays/intents exportés, correction du chemin RSS/DNS, renforcer l’estimateur de mot de passe, simplifier le RNG. OTF affirme aujourd’hui que les enjeux de l’audit 2017 ont été corrigés; le rapport 2017 ne contient pas de retest indépendant de ces correctifs. Il qualifie l’app testée d’early-stage et recommande un second audit après développement.
  • Conséquence : historique utile pour endpoint/app, mais ni vulnérabilité actuelle démontrée ni audit de la version actuelle.

Briar — Radically Open Security / OTF, septembre–octobre 2023, retest février–mars 2024

  • FACT — organisme/date/durée/méthode : Radically Open Security, engagement OTF Security Lab « crystal-box/white-box ». Période 21 septembre–31 octobre 2023; effort 24–26 jours (préparation, test Android/desktop, analyse protocoles/crypto, retest, revue et coordination) selon le rapport PDF indexé. Page OTF et findings, rapport complet PDF.
  • Scope : clients Android et desktop; protocoles et cryptographie Android. Pas d’indication d’audit de la gouvernance, des stores ou de toutes les distributions de binaires.
  • Findings : six problèmes — un risque modéré et cinq faibles, aucun dans les catégories OTF Extreme/High/Elevated. Modéré OTF-001 : attaque overlay sur l’app Android; le rapport signale l’atténuation Android 12+ avec Window.setHideOverlayWindows(true). Faibles : OTF-002 PSK trop courte pour le partage Wi-Fi du paquet (attaquant proche pendant le partage initial pourrait tenter brute-force puis injecter un paquet); OTF-003 socket TCP de l’app/service Tor sans isolation Android équivalente aux Unix domain sockets; OTF-004 protections stack overflow; OTF-005 impossibilité pour un contact initialement distant d’élever ultérieurement son niveau de vérification; OTF-006 la dénégation plausible dépend du type de contenu et n’est pas identique pour messages, forums, blogs et groupes, sans être explicitée dans la documentation utilisateur.
  • Recommandations : masquer overlays sur Android 12+, doubler longueur PSK, utiliser Unix sockets pour app/Tor, activer stack canaries et _FORTIFY_SOURCE, permettre une vérification ultérieure (QR/SMP analogue), documenter les limites de dénégation.
  • Retest/corrections : ROS a retesté en fév.–mars 2024; quatre des six issues résolues. OTF dit explicitement qu’OTF-003 et OTF-005 étaient encore planifiées pour correction. La page ne donne pas commit/build précis ni la correspondance complète des quatre correctifs au retest. Le PDF hébergé a répondu 403 dans l’outil de lecture; l’extraction actuellement exploitable provient des passages indexés du PDF et de la synthèse OTF, donc la lecture intégrale page par page reste à faire.

Threema — audit de code IT Security Group, Hochschule Münster, 2018–2019

  • FACT — rapport/source : rapport signé Fabian Ising, Damian Poddebniak et Sebastian Schinzel, daté du 28 mars 2019; période octobre 2018–janvier 2019; 22 jours-personne. Rapport complet PDF.
  • Scope : audit source Android v3.54, iOS v3.0.9 et Threema Safe Android; code serveur hors scope; quelques tests live avec apps de production. Revue visant aussi les déclarations du whitepaper cryptographique.
  • Findings : deux médiums et plusieurs faibles/informatifs. Une app Android malveillante pouvait lancer un partage contenant des fichiers privés, potentiellement key.dat, mais la victime devait encore choisir le contact destinataire; fragments du mot de passe Threema Safe présents dans un log interne Android. Aucun high/critical, pas d’écart au whitepaper rapporté.
  • Corrections : le rapport dit que toutes les findings medium/low ont été corrigées en Android 3.62 et iOS 4.1 (correctifs souvent en heures ou jours). Aucun retest post-correction détaillé n’est décrit. Ce n’est pas un audit serveur, de l’infrastructure ou de versions actuelles.

Threema — Cure53, apps mobiles, octobre 2020

  • FACT — durée/méthode : 4 membres Cure53, 16 jours-personne sur la semaine CW42; white-box et sources fournies. Rapport Cure53 du 30 octobre 2020. Rapport complet.
  • Scope : Android, iOS, Sodium/NaCl et intégration crypto. Stockage Android inspecté via adb sur appareil rooté Android 9 + deux émulateurs x86; stockage iOS sur appareil jailbreaké iOS 13.3.1/checkra1n. Interception réseau, TLS invalide, logs, attaques locales et VoIP examinés. Versions exactes d’app/commit non données dans les passages de scope parcourus.
  • Findings : huit problèmes, aucun considéré comme vulnérabilité exploitable dans l’engagement; sept informatifs/faibles et un medium. L’index cite cache client iOS (NSURLCache) et fichiers d’état/snapshots, protections filesystem iOS perfectibles, dépendance GIF Android ancienne, absence FORTIFY_SOURCE dans plusieurs libs tierces, capture auto de screenshots révélant temporairement des informations, comparaison de PIN non timing-safe, recommandations de réglages.
  • Observation de stockage importante, historique : Android stockait DB chiffrée; AES-256 master key dans key.dat, sans passphrase locale la clé pouvait être récupérée par un acteur déjà hautement privilégié/root; avec passphrase, les testeurs n’ont pas identifié de contournement. iOS : DB Core Data chiffrée et clé privée Keychain AfterFirstUnlockThisDeviceOnly; pas de contournement observé dans les conditions testées. L’audit n’établit pas les versions ni le comportement d’appareils actuels.
  • Remédiation/retest : pas de réexamen indépendant post-correction identifié dans ce rapport. Il faut faire correspondre ces conclusions anciennes à la politique de passphrase, au stockage et aux versions présentes.

Threema Desktop — Cure53, janvier 2024

  • FACT — organisme/date/durée : Cure53, cinq testeurs seniors, 16 jours en CW03–CW04 2024; commandité par Threema GmbH. Rapport Cure53 PDF, index officiel des audits.
  • Version/scope : Desktop 2.0 Beta 26. Test white-box de l’interface Svelte, backend et IPC, communication réseau; code source et builds multi-OS fournis. Pas audit des applis mobiles dans ce mandat.
  • Findings/remédiations listées dans le rapport : 3 vulnérabilités : SVG preview pouvant provoquer DoS (Low, corrigé Beta 28); type de fichier/accès propriété non sûr provoquant DoS d’une room (Medium, Beta 28); fichiers téléchargés sans macOS quarantine flag (Low, Beta 28). Quatre general weaknesses : réglages Electron worker potentiellement propices à RCE si un XSS était déjà obtenu (étiqueté « High » dans le titre; Threema dit qu’il ne peut pas simplement retirer Node integration/sandbox en raison d’une limite Electron et a ajouté CSP stricte + SRI Beta 43); CSP insuffisamment restrictive (Medium, Beta 28 puis renforcée Beta 43); prototype pollution par postMessage (Info, Beta 31); contournement de navigation via History API (Info, Beta 31).
  • Contradiction interne à conserver : le rapport classe 3MA-03-004 « High » dans son titre, mais indique dans son résumé qu’aucun finding Critical ni même High-scored n’a été relevé; le même document distingue vulnérabilités réelles et general weaknesses à faible potentiel d’exploitation. Le rapport n’explique pas complètement cette discordance de libellé. Il dit aussi qu’aucun XSS n’a été découvert; la chaîne RCE était une conséquence conditionnelle si XSS existait.
  • Retest : fix notes versionnées dans le rapport, mais pas de retest externe post-fix identifié. Cure53 a néanmoins inspecté SQL local chiffré, vérifié absence de fuite claire dans les fichiers examinés, pinning/hostname verification et traitement des certificats invalides dans le build testé.

Threema Ibex — analyse cryptographique académique, juillet 2023

  • FACT / source : Paul Gerhart, Paul Rösler et Dominique Schröder, 30 juillet 2023, analyse avec preuve de sécurité publiée par le groupe de cryptographie appliquée d’Erlangen–Nuremberg (PDF 38 pages). Analyse complète, notice éditeur.
  • Périmètre et résultat : preuve formelle pour le protocole de canal/échange continu de clés Ibex selon un modèle donné, sous hypothèses GDH/Random Oracle; confidentialité, authenticité/intégrité, replay resilience et forward security. Ce n’est pas une pentest de l’app, du serveur ou du client courant.
  • Limites explicitement écrites par les auteurs : analyse ne prouve pas la sécurité circulaire de la double encryption; suppose les clés publiques vérifiées hors bande/administrateur ou une PKI honnête; client desktop lié au mobile exclu. Recommande de travailler la résistance post-quantique, et note que le modèle de groupes un-à-un ne protège pas complètement l’existence/structure des groupes si le serveur analyse les motifs de communication; envisage des protocoles de type anonymous ratchet/ORAM.
  • Contradiction/cadrage : l’affirmation marketing Threema selon laquelle « aucun tiers, pas même le serveur, ne peut identifier les participants » ne doit donc pas être étendue à la présence et structure des groupes sous analyse de motifs. La preuve Ibex valide des propriétés formalisées du protocole ciblé, pas l’anonymat global ni l’observation de trafic serveur.

Delta Chat Webxdc — Cure53 / OTF, février–mars 2023

  • FACT — durée/méthode : Cure53, 4 testeurs seniors, 12 jours, white-box; demandé en février et exécuté semaines de travail 11–13 de mars 2023. Rapport PDF, récit OTF.
  • Scope : promesse de confidentialité Webxdc et revue de spécification; implémentations Android, iOS et desktop des mini-apps; période et build précis du rapport connus comme releases de février 2023, mais commit exact pas encore extrait.
  • Findings : 7 total, 5 vulnérabilités et 2 problèmes informatifs. Cinq High dans les versions auditées : exfiltration DNS-prefetch desktop; bypass CSP complet par webxdc.js desktop; exfiltration DNS lookup Android; exfiltration via DevTools desktop; bypass CSP par inclusion PDF desktop. Info : recommandation selfAddr spoofable dans payload et manque d’en-tête CSP pour webxdc-update.json iOS.
  • Corrections : blog de l’équipe indique corrections high par séries v1.36 (avril 2023), cite PR/commits desktop/Android/iOS et explique les limites Chromium (DNS prefetch/WebRTC). Les deux informatifs avaient décisions distinctes : API selfAddr à faire évoluer, CSP iOS corrigée. Retest externe formel après les fixes n’est pas établi par les sources consultées.
  • Portée : cet audit valide spécifiquement la sandbox Webxdc d’un ensemble de clients en 2023; il ne faut pas l’appliquer au transport SMTP/IMAP ni à chaque Webxdc personnalisé actuel.

Delta Chat — analyse ETH Zürich / USENIX Security 2024 (SecureJoin/Autocrypt/rPGP)

  • FACT / source indépendante : Yuanming Song, Lenka Mareková, Kenneth G. Paterson, USENIX Security 2024, « Cryptographic Analysis of Delta Chat ». Paper ETH/USENIX, fiche publication ETH.
  • Résultat : les chercheurs décrivent cinq nouvelles attaques dans le modèle de menace Delta Chat, issues d’interactions SecureJoin/Autocrypt et de bugs dans rPGP. Responsibly disclosed; l’éditeur indique 20 issues au total dans ses corrections de hardening et incorporation dans Delta Chat v1.44 avant divulgation, ce qui peut comprendre des vulnérabilités et problèmes/durcissements connexes, et ne doit pas être assimilé automatiquement au nombre « cinq attaques » du papier.
  • Limite : papier academic peer-reviewed/USENIX et correctifs répertoriés par la source mainteneur; ce n’est pas un audit actuel de tous les clients, de l’email, des fournisseurs chatmail, ni une preuve de retest indépendant de chaque patch. La chronologie et détails de corrections sont dans l’article officiel du 25 mars 2024.

Delta Chat — précisions d’implémentation courante, stockage et mobile (contrôle au 13 octobre 2026)

  • FACT — versions observées dans les listings : le repo Android publie v2.62.0 le 26 septembre 2026 (commit 97161cc, marqué “Verified” par GitHub); F-Droid avait v2.62.0, build 7584, le 28 septembre, Android 5+. Le repo Desktop publie v2.62.0 du 26 septembre, commit 8f8ffd7 également marqué vérifié par GitHub. Un tag/commit signé améliore l’authenticité du source annoncé; ce n’est pas une preuve que les binaires Google Play/App Store ou GitHub sont bit-à-bit reproductibles. Android releases, F-Droid listing, Desktop release.
  • F-Droid / build : le listing F-Droid dit que son APK est construit et signé par F-Droid et correspond au tarball source référencé, et fournit une signature PGP et un build log. Le fetch du tarball, de la signature et du log par l’outil de navigation a échoué (cache miss); je n’ai pas téléchargé ni comparé le binaire au source. Fait établi : provenance de build déclarée par F-Droid. Inconnu : reproduction indépendante effective, résultat de comparaison binaire et équivalence avec Play/App Store.
  • Permissions déclarées par F-Droid pour ce build : localisation approximative/précise au premier plan, caméra, microphone, Bluetooth (incluant appareils voisins), fichiers/images/vidéos, réseau, démarrage, notifications et services de premier plan sont listés. Le fournisseur dit que caméra = photo/QR/appels vidéo, micro = messages vocaux/appels, position = partage volontaire, fichiers/photos = joindre/enregistrer et biométrie = verrouillage local. Le listing expose les capacités requises par le manifeste/build F-Droid, pas la preuve qu’elles sont utilisées en permanence; la page ne liste pas READ_CONTACTS, mais le manifeste APK n’a pas été extrait ici. F-Droid permissions, privacy policy.
  • Contacts / analytics / tiers : le changelog Android ajoute explicitement en v1.43 un réglage opt-in “Read System Address Book”; l’historique indique la sélection manuelle de ce réglage, donc ne pas confondre import local avec upload du carnet. L’éditeur dit que la statistique hebdomadaire Android est facultative, envoyée à un bot seulement après opt-in, avec exemples de fonctions utilisées/erreurs, et qu’elle ne contient rien d’identifiant. Cela demeure une déclaration éditeur; l’extraction du binaire et une capture réseau n’ont pas été faites. Le changelog dit que le build F-Droid/non-Google-Play désactive FCM; le build Android ordinaire utilise FCM seulement si le fournisseur et l’OS le prennent en charge. Changelog Android, policy, FAQ stats/push.
  • Mise à jour réseau / résilience : v2.62.0 indique que le nouvel onboarding sélectionne aléatoirement plusieurs relais au lieu d’un seul relais par défaut codé en dur; les messages sont interrogés sur tous les relais et envoyés via le plus rapide lors de la configuration initiale. C’est une évolution de disponibilité et concentration du service, pas une preuve d’anonymat réseau. Le client et la métadonnée d’adresse restent dépendants des relais choisis par le compte.
  • Stockage local — point à ne pas figer à partir de l’audit 2020 : l’audit Include Security 2020 a constaté sur Delta Chat 1.39.0 une DB/backup non chiffrée; un audit Cure53 de 2023 a trouvé la DB desktop non chiffrée contenant des données d’accès. Les API Rust documentent encore des opérations d’export DB avec passphrase, mais la documentation générée du cœur indique que le chiffrement DB est déprécié depuis novembre 2025 car les blobs restent non chiffrés et recommande plutôt le chiffrement filesystem/disque, nécessaire aussi pour l’isolation des apps. Ainsi, le mécanisme optionnel ancien ne doit pas être décrit comme protection complète des données locales courantes. API ContextBuilder, API DB.
  • Sauvegarde — incertitude restante : l’aide courante dit que l’export manuel demande le PIN/schéma/mot de passe de déverrouillage système, puis un fichier est transféré/restauré manuellement; elle n’affirme pas que l’archive est cryptographiquement chiffrée avec une clé indépendante. Le rapport 2020 prouvait que le backup .bak du build 1.39.0 se lisait comme SQLite et exposait messages, clés et pièces jointes; les réponses publiques du forum en 2023 disent que le tar contient DB et médias sans chiffrement. Le cœur actuel expose export_backup(..., passphrase) et export_backup_stream, mais je n’ai pas vérifié l’argument utilisé par le GUI v2.62.0 ni le chiffrement de tous les blobs dans l’archive. Conclusion probatoire actuelle : archive v2.62.0 et contenu exact UNKNOWN sans inspection du code de l’appel/UI ou essai contrôlé; ne pas affirmer qu’elle est sûre parce qu’un PIN système est demandé, ni affirmer sans réserve que la version actuelle est identique au backup 2020. FAQ sauvegarde, code API export/import, audit 2020, discussion technique 2024.
  • FS / PQ — contradiction “prévu en 2026” vs état actuel : la FAQ officielle dit explicitement que Delta Chat ne prend pas encore en charge Perfect Forward Secrecy ni le post-quantique; Autocrypt v2 est “scheduled for full implementation in 2026” et doit apporter rotation de clés/PFS et PQ. L’annonce v2.62.0 parcourue ne mentionne pas la livraison d’Autocrypt v2; aucun changement de protocole ou étude indépendante de disponibilité en stable 2.62.0 n’a été localisé. Donc, au 13 octobre 2026, le statut sûr est NON ÉTABLI comme livré dans les apps stables; l’existence d’une échéance de roadmap n’est pas une preuve de fonctionnalité. FAQ cryptographie, release 2.62 Android, release Desktop.
  • Contenu vs en-têtes email : la doc dit que le message chiffré protège texte, pièces jointes et leurs noms; elle décrit néanmoins les adresses expéditeur/destinataire et taille de message comme visibles aux serveurs, tandis que les groupes/contacts sont localement conservés et leur metadata incluse dans la partie E2EE. À cette date, le transport peut aussi être du courrier classique non E2EE si le correspondant/service ne prend pas en charge le flux Delta Chat; la FAQ le distingue explicitement du chatmail et recommande l’icône “email” comme avertissement. Ce sont des comportements documentés par le projet; une analyse de paquets actuelle reste à faire. FAQ metadata, FAQ transport/limitations.

Complément — lecture des rapports complets Delta Chat 2019, 2020 et 2023

Include Security / OTF, rPGP + RustCrypto RSA, 2019

  • Organisme / calendrier : Include Security, audit financé par Open Technology Fund; effort déclaré de 9 jours entre le 3 juin et le 5 juillet 2019, dont 24 heures sur RSA et 48 heures sur rPGP. La copie publique porte encore la mention « CONFIDENTIAL — DRAFT REPORT ». Le test concernait les derniers commits de master au 3 juin, mais le PDF ouvert ne donne pas un SHA de commit exploitable dans son corps. Les dépendances de ces bibliothèques n’étaient pas auditées et l’équipe précise que le temps n’était pas exhaustif. Rapport PDF
  • Findings : 10 au total : 2 High, 1 Medium, 5 Low, 2 Informational, aucun Critical. High : récupération de plaintext par erreur de validation du MDC OpenPGP; dépendance slice-deque 0.1.16 avec vulnérabilité memory-corruption connue, sans analyse d’exploitabilité dans ce mandat. Medium : oracle « quick check » pouvant révéler des octets de plaintext. Low : boucle infinie sur paquet incomplet; clés/messages sensibles potentiellement journalisés; DoS RSA par grosse clé publique; panic sur ciphertext incomplet; chiffrement permis avec une sous-clé dont les flags n’autorisent pas le chiffrement. Info : API ne permettant pas de désactiver/détecter certains paquets sans protection d’intégrité; bibliothèque en développement actif pendant l’audit.
  • Recommandations / remédiation : réponses de déchiffrement génériques sans plaintext/oracle, mettre à jour les dépendances et intégrer cargo-audit, rejeter proprement les paquets incomplets, éviter journaux contenant des secrets, borner les clés/ressources, respecter les key flags. Delta Chat déclare que les deux High ont été corrigés; certains autres problèmes aussi, mais ne publie pas une correspondance exhaustive finding → commit → version → retest dans la FAQ. Le problème quick-check est déclaré corrigé dans rPGP 0.11 en 2024. Retest externe post-correctif : non établi. FAQ audit officielle, chronologie rPGP 0.11.
  • Lecture bornée : ce rapport porte sur les bibliothèques crypto de 2019, pas sur les applications actuelles, les serveurs mail, ni sur l’usage en production de chaque finding.

Include Security / OTF, Delta Chat Rust core et bibliothèques réseau, 2020

  • Organisme / calendrier / version : Include Security pour OTF; le rapport décrit un effort de 12 jours du 6 au 21 août 2020, après début d’analyse indiqué au 13 juillet; Delta Chat 1.39.0. Méthode « standard grey-box », revue des bibliothèques Rust deltachat-core-rust, async-smtp, async-imap, async-native-tls, plus tests avec Android et Desktop. Le code Electron et le code spécifique mobile Android/iOS étaient hors scope; tests dynamiques limités. Le fuzzing a été utilisé avec parcimonie et le rapport dit que davantage de temps aurait été nécessaire. Pas de SHA de commit disponible dans les passages de cadrage consultés. Rapport PDF
  • Findings : 16 : 6 Medium, 8 Low, 2 Info; aucun High/Critical. Les six Medium sont : (M1) contenu/credentials transmis en clair si le compte est mal configuré sans TLS; (M2) messages, clés, mots de passe email et autres éléments dans SQLite en clair à l’époque, avec risque en cas d’accès au fichier/backup cloud; (M3) exports/backups non chiffrés; (M4) SSRF via URL contrôlée par l’utilisateur; (M5) tromperie par groupe ayant nom/avatar d’un utilisateur; (M6) type de contenu des fichiers non validé, extension falsifiable, pièces écrites automatiquement. Les huit Low : métadonnées en logs/config/local storage même en mode éphémère; CSP desktop autorisant unsafe-inline; limites d’envoi mais limites entrantes insuffisantes (DoS); SHA-1 encore sélectionnable/préféré; protections de compilation PIE/RELRO/stack cookie manquantes; usage unsafe/déréférencement; homographes; avertissement UI insuffisant sur la perte possible de confidentialité. Les deux Info portent sur une séquence de traversée de chemin théorique (les / et \\ étant normalisés dans le cas décrit) et des considérations de surface d’attaque, trafic et cryptographie post-quantique.
  • Recommandations : TLS strict et avertissement clair sur le non-chiffré; chiffrement du stockage et exports avec clé robuste/KDF; filtrer les URLs/SSRF; rendre groupes vs conversations individuelles plus distincts; valider type et taille des fichiers; limiter la journalisation et la persistance des métadonnées éphémères; durcir CSP, SHA-1 et flags de compilation, réduire unsafe, améliorer l’affichage des noms/alertes.
  • Corrections / retest : la FAQ actuelle du projet ne prétend pas que tout a été corrigé : elle qualifie les faiblesses Medium de dépendantes de l’environnement, et dit que compatibilité/usabilité empêche d’en atténuer toutes; elle donne des recommandations aux utilisateurs exposés. Aucun tableau de correction finding-par-finding ni retest indépendant post-correctif n’a été trouvé. Ce rapport ancien décrit donc un état historique de 1.39.0, non les builds actuels. FAQ officielle.

Cure53, mail-server template et bibliothèques Delta Chat, 2023

  • Organisme / durée / version : Cure53; trois testeurs seniors nommés; 10 jours alloués, préparation CW06 et exécution CW07 février 2023; rapport daté du 22 février 2023. White-box sur repositories mailcow-dockerized, mailadm, deltachat-core-rust, async-smtp, async-imap, async-native-tls, native-tls, fast-socks5 et instance de test. Aucun SHA de commit client n’est indiqué dans le rapport. Rapport PDF, annonce de l’équipe.
  • Scope / exclusion : mail server-template, bot/gestion mailadm, dépendances configurées, parties du core Rust, TLS et flux réseau; ce n’est pas l’audit général de toutes les apps mobiles ou de toute infrastructure publique. Le rapport dit avoir validé les configurations SMTP/IMAP/TLS de son setup de test, et son analyse SMTP n’a pas trouvé de downgrade exploitable.
  • Findings détaillés : huit, annoncés par Cure53 comme quatre vulnérabilités et quatre faiblesses générales : (High) MER-01-008, injection de commande shell dans la fonction mailcow Sync Job, exploitable uniquement si une permission supplémentaire est attribuée au compte; (Medium) MER-01-004, validation email divergente entre composants, laissant créer des comptes permanents/non supprimés; (Low) MER-01-003, DB SQLite desktop non chiffrée et contenant données de connexion; (Low) MER-01-005, traversal dans la construction d’une requête API mailcow; (Low) MER-01-001, traversal lors de la création QR par nom de token, jugée non exploitable au test car Pillow vérifiait les dossiers existants; (Info) MER-01-002, dépendances alors vulnérables/anciennes (libsqlite3-sys 0.24.2, time 0.1.44); (Low) MER-01-006, absence de version TLS minimale explicitement configurée, surtout pertinente pour OS anciens; (Info) MER-01-007, base statique de fournisseurs email pouvant inclure des réglages potentiellement faibles ou être altérée.
  • Recommandations / corrections : validation stricte/unique des adresses et noms de fichiers, corriger l’injection Sync Job (temporairement supprimer XOAUTH2 selon Cure53 si nécessaire), protéger la DB desktop par passphrase, mettre à jour les dépendances avec contrôle automatisé CI, fixer TLS minimum à 1.2, générer et vérifier l’intégrité de la base fournisseurs. Le billet de Delta Chat déclare l’injection corrigée dans une mise à jour mailcow de mars 2023, la commande bot medium corrigée, et les six findings Low/Info « corrigés ou à traiter dans de futures versions » sans correspondance exhaustive publique. Aucun retest indépendant n’est rapporté. Cure53 recommande explicitement une nouvelle évaluation de mailcow.
  • Limite : le PDF a été lu; contrairement à des résultats sommaires, ce n’est pas un constat que le réseau Delta Chat « n’a pas de vulnérabilités ». L’évaluation a vu un template/instance défini, et non tous les opérateurs, hébergeurs ou déploiements.