Duniter v2.3.0 : mise à jour de sécurité pour Ğ1 et ĞTest

J’ai trouvé plusieurs vulnérabilités dans Duniter, à différents niveaux de sévérité, que j’ai patchées dans cette version v2.3.0. Je recommande vivement à tous les hébergeurs de nœuds Duniter de mettre à jour dès que possible. Voici les nouvelles images Docker :

Ğ1 : duniter/duniter-g1-1100:1100-2.3.0
ĞTest : duniter/duniter-gtest-1000:1100-2.3.0

Je donnerai plus de détails sur ces vulnérabilités lorsque la plupart des nœuds auront été mis à jour (et, a minima, les nœuds forgerons). Il ne faudrait pas dévoiler des informations qui pourraient faciliter une attaque par quelqu’un de mal intentionné.

Comment ai-je trouvé ces vulnérabilités ?

J’ai obtenu l’accès au programme Daybreak Blue d’OpenAI, ce qui permet d’utiliser leurs modèles pour de la cybersécurité défensive (recherche de vulnérabilités afin de les corriger). J’ai utilisé cet accès pour auditer Duniter en profondeur, ce qui m’a permis de trouver plusieurs vulnérabilités effectivement exploitables !

Vous ne le savez peut-être pas, mais, par défaut, il n’est pas possible d’utiliser les modèles d’IA frontier d’OpenAI et d’Anthropic pour rechercher des vulnérabilités de sécurité dans votre codebase. Ils peuvent faire un audit de surface et améliorer les bonnes pratiques de sécurité dans votre codebase, mais dès que vous essayez de rechercher des vulnérabilités précises, vous êtes stoppé et on vous invite à basculer sur un modèle moins puissant pour continuer, car de telles demandes pourraient être utilisées pour lancer des cyberattaques.

Les modèles à poids ouverts n’ont pas ces limitations, mais ils ont quelques mois de retard sur l’état de l’art des modèles d’OpenAI et d’Anthropic, et ils coûtent plus cher en pratique. En effet, les plus gros modèles à poids ouverts, comme Kimi K3 par exemple, requièrent un datacenter. Il faut donc payer un fournisseur, avec un coût à l’inférence plus élevé comparé aux abonnements subventionnés que proposent OpenAI et Anthropic. (Pour 200$ par mois, vous avez plus de 5 000$ d’inférence au prix de l’API.)

Aussi, les modèles à poids ouverts sont accessibles aux attaquants. Pour pouvoir se défendre, il faut donc trouver et patcher les vulnérabilités avant que les modèles à poids ouverts soient capables de les trouver. C’est pour toutes ces raisons que je me suis inscrit au programme de cyberdéfense d’OpenAI en tant que développeur indépendant.

Je vous invite à le faire aussi si vous êtes en capacité de payer un abonnement chez OpenAI. Même un abonnement à 25 € par mois y donne accès, avec un nombre de tokens assez limité, cela dit. Les conditions sont simples : vous devez remplir un KYC (fournir une pièce d’identité et scanner votre visage en 3D) et sécuriser l’accès à votre compte via une YubiKey. Après quelques vérifications de leur côté, vous aurez alors accès au modèle « Daybreak Blue ».

Attention : l’usage de ce modèle est monitoré à des fins de vérification. Ne l’utilisez pas pour des projets dont le code n’est pas public et ne lui communiquez pas d’informations personnelles.

Les autres labos d’IA ont des programmes similaires, mais réservés aux entreprises qui doivent en faire la demande pour leurs red teams internes, avec des restrictions beaucoup plus fortes.

OpenAI est le seul labo, à ce jour, qui donne aux développeurs indépendants l’accès à des capacités de cyberdéfense pour leurs projets. C’est donc le seul que vous pourrez utiliser pour les logiciels de la Ğ1, à moins de travailler pour une entreprise qui a de tels accès et vous autorise à les utiliser pour vos projets perso (bon courage…).

Vu les capacités de cyberattaque que possèdent désormais les modèles à poids ouverts, il devient indispensable de pouvoir utiliser les modèles frontier pour trouver et corriger les vulnérabilités critiques avant que les modèles à poids ouverts ne soient en capacité de les exploiter. Tous les principaux labos d’IA devraient fournir ces capacités aux mainteneurs de logiciels libres. Je suis choqué que seul OpenAI propose un programme adapté pour cela !

Dans les prochaines semaines, je veux bien essayer de consacrer une partie de mon quota d’usage à trouver et patcher des vulnérabilités dans d’autres logiciels de la Ğ1. Mais cela demande beaucoup de tokens, et j’ai aussi besoin d’en garder pour mes propres usages. Tout ne peut donc pas reposer sur moi.

C’est pourquoi il me semble important que d’autres développeurs de la Ğ1 demandent l’accès au programme Daybreak d’OpenAI afin d’aider à renforcer l’écosystème Ğ1 avant que les capacités de cyberattaque des modèles à poids ouverts ne fassent encore de nouveaux progrès.

@moderators quelqu’un peut t’il tagger @smiths-v2 ? (Je n’ai pas le droit de tagger ce groupe)

Fais pour ma part : miroir et forgeron sous duniter/duniter-g1-1100:1100-2.3.0

Forgeron ǦTest mis à jour, go-offline fait sur la Ğ1 pour mise à jour sans risque d’interruption non annoncée (il reste assez de forgerons en ligne).

J’ai fait relire le diff à un agent, je confirme les failles et leur correction.

@smiths-v2 Pensez à mettre à jour :slight_smile:

Je viens de mettre à jour tous mes noeuds.

Fait.
Merci pour le ping.

fait, j’avais accidentellement mis à jour après une relance et un pull au préalable hier

Hello, mises à jour en cours pour Ğ1 et ĞTest de mon côté et du côté @Sleoconnect :slight_smile:

Done in my side.

Merci merci for the security review.

J’ai annoncé sur le site Duniter : Duniter | Duniter v2.3.0 : mise à jour de sécurité

@Rebirth35 @Josephin @1000i100 et d’autres il faut mettre à jour !

@aya tu sais qui gère celui qui s’appelle “axiomteam” ?

pourquoi duniter-gtest-1000 et non duniter-gtest-1100 ?

à part ça, mise à jour g1 faite, gtest en cours.

J’avais déjà répondu à cette question ici: Duniter-gtest v2.0.5 (bootnodes GTest et configuration du hard fork GRANDPA) - #3 by elois

C’est moi :wink:
J’ai mis à jour le noeud gt.axiom-team.fr sans encombre mais j’ai rencontré un pb sur le noeud g1.axiom-team.fr. J’utilise les paquets debian pour les 2 serveurs et j’ai l’impression qu’il y a un pb avec le paquet duniter_2.3.0-1_amd64.deb.

duniter@open:~$ RUST_BACKTRACE=full /usr/bin/duniter --chain g1 --name axiomteam-g1-archive --listen-addr /ip4/0.0.0.0/tcp/30333 --rpc-cors all --state-pruning archive
--base-path /home/duniter/.local/share/duniter --rpc-rate-limit-trust-proxy-headers --public-addr /dns/g1.axiom-team.fr/tcp/30333 --public-rpc wss://g1.axiom-team.fr/ws
/ --public-squid https://g1-squid.axiom-team.fr/

thread 'main' (1803803) panicked at node/src/command.rs:283:26:
unknown runtime
stack backtrace:
   0:     0x557e3c20ae53 - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::hac1d885928ba8582
   1:     0x557e3a153937 - core::fmt::write::h83ebb4d32483be9e
   2:     0x557e3c1d9366 - std::io::Write::write_fmt::ha6a1d6c1ea64b2d0
   3:     0x557e3c1e83d9 - std::panicking::default_hook::{{closure}}::h8e9c4d1276f0925f
   4:     0x557e3c1e820f - std::panicking::default_hook::h2b2078d38b534dfb
   5:     0x557e3c1e86bb - std::panicking::panic_with_hook::h39b739724e701bfd
   6:     0x557e3c1e84ca - std::panicking::panic_handler::{{closure}}::he540c4833054e458
   7:     0x557e3c1e2ef9 - std::sys::backtrace::__rust_end_short_backtrace::hfa179d89deec8aed
   8:     0x557e3c1cc79d - __rustc[d131491b17107b07]::rust_begin_unwind
   9:     0x557e3a15e37c - core::panicking::panic_fmt::ha564519d657d9c46
  10:     0x557e3ad2651f - duniter::command::<impl sc_cli::SubstrateCli for duniter::cli::Cli>::load_spec::h591585fffa9aa0b6
  11:     0x557e3a972eeb - sc_cli::config::CliConfiguration::create_configuration::he03fe2ad424d8dd0
  12:     0x557e3ad1b8f1 - duniter::command::run::h58b064d66d87960f
  13:     0x557e3ae0c159 - duniter::main::hf34d1ff1ee2a4189
  14:     0x557e3af1b956 - std::sys::backtrace::__rust_begin_short_backtrace::hf51695afd396b0e7
  15:     0x557e3ae747b5 - std::rt::lang_start::{{closure}}::h8a5c3bc4f24c4f58
  16:     0x557e3c1daf0f - std::rt::lang_start_internal::h74b643a2cc7fe3b4
  17:     0x557e3ae30a45 - main
  18:     0x7f78d1cab24a - __libc_start_call_main
                               at ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
  19:     0x7f78d1cab305 - __libc_start_main_impl
                               at ./csu/../csu/libc-start.c:360:3
  20:     0x557e3a05a7e1 - _start
  21:                0x0 - <unknown>

Suite à une tentative infructueuse de @poka, je précise le processus à suivre pour les personnes intéressées :

Il faut d’abord créer un compte OpenAI ou s’y connecter, puis souscrire à un abonnement Plus ou Pro. Ensuite, passez par https://chatgpt.com/cyber pour effectuer votre KYC.

Après cela, dans les paramètres de votre compte, il faut activer le niveau de sécurité maximal avec une YubiKey. Cela désactive les autres méthodes de 2FA, et c’est obligatoire. Normalement, toute la procédure est assez rapide.

Une fois l’accès obtenu, vous ne payez rien de plus : c’est inclus dans votre abonnement. Dans la liste des modèles, vous aurez alors accès à un modèle nommé « Daybreak blue », qui correspond en fait au modèle GPT-5.6 Sol en mode débridé.

Tu avais bien utilisé le bon lien. GitLab renvoyait le paquet GTest à la place du paquet G1, ce qui provoquait l’erreur « unknown runtime ». Le problème venait des liens de publication.

Les liens sont maintenant corrigés : @aya tu peux retélécharger le paquet depuis la release G1 v2.3.0 et le réinstaller.

Le paquet de la v2.3.1 corrige le pb, merci !