Samuel a écrit 144 commentaires

"L'école nationale supérieure" est en fait "l'école normale supérieure" (où enseignait Georges Bruhat, il a même cofondé le laboratoire de physique. De même, sa fille était étudiante à l'école normale supérieure de Sèvres (et non pas nationale, deuxième titre).

La question porte sur les contenus générés par IA.

Il me semble que la question des contenus corrigés par IA ou améliorés (en terme de syntaxe, tournure de phrase) par ce genre de systèmes, visant à rendre un texte plus lisible, est une question différente. Typiquement, le cas d'usage que tu présentes me semble a priori acceptable (si la question m'était posée …), alors que je suis fermement opposé à la présence de textes générés par IA.

J'ajoute que je remercie l'auteur du journal d'avoir fait l'effort de tenter d'expliciter sa pensée Ukemiste avec ses mots, ici (i.e. en-dehors du cercle des personnes qui pensent avec ces outils). En tant que personne qui essaie de comprendre ces modes de pensée, ça m'est très utile.

Pour une vision plus critique du rationalisme (ou de l'ukemisme), je renvoie les curieuses et curieux au texte The TESCREAL bundle: Eugenics and the promise of utopia through artificial general intelligence de Timnit Gebru et Emilio P Torres.

En très très très résumé :

• un ensemble d'idéologies plus ou moins proches ont émergé ces 30 dernières années (Transhumanisme, Extropianism, Cosmism, Rationalism, Effective Altruism, Longtermism)
• ces idéologies ont une filiation idéologique et conceptuelle avec l'eugénisme (y compris dans ses dimensions racistes)
• elles reposent en partie sur une eschatologie autour de l'IA (vision de fin du monde tel que nous le connaissons, pour le meilleur ou pour le pire)
• depuis 10 ans, des milliards sont investis par ces gens pour créer une "IA Générale" (capable de faire n'importe quelle tâche) pour faire advenir le bonheur de l'humanité. On retrouve ainsi ces croyants à la tête d'OpenAI et d'Anthropic et les concepts développés par les TESCREALs au cœur de la stratégie de Meta en matière d'IA

En gros, les idées ne flottent pas en l'air. Elles ont une histoire, un contexte, une situation d'énonciation, des soutiens matériels et financiers et des effets sur le monde réel.

Je note que, dans le package TESCREAL, le rationalisme/l'ukemisme et l'effective altruisme sons sans doute les moins bizarres, ou du moins ceux dans lesquels on peut trouver des idées intéressantes (mais, à mon avis, très étrangement formulées et tirées beaucoup trop loin).

malgré toutes ses casseroles^W hallucinations (dont beaucoup ne sont pas de son fait…).

À propos du terme "hallucinations", Thibault Prévost interrogé par Mediapart expose :

Dans une tentative de dépolitiser le problème, la Silicon Valley essaye de redéfinir les erreurs de l’IA comme des « hallucinations », en nous obligeant à une forme de tendresse par rapport aux machines, qu’il faudrait éduquer. Je suis absolument contre l’usage de ce terme : il s’agit d’erreurs de calcul, de désinformation, intrinsèques au modèle.

(source: Trumpisme, biais racistes et menace écologique : « L’IA n’est pas une technique, c’est une idéologie », 19/01/2025, article payant).

Actuellement, la bataille autour des mots semble gagnée par les bullshitters de tous poils, je rejoins l'auteur du post initial sur la nécessité de défendre des positions aussi sur ce plan là (même si nous sommes avons le sentiment d'être quasiment inaudibles aujourd'hui).

La source semble être : https://torrentfreak.com/images/20241024_-_Jugement_TJ_Paris_24_oct._2024_UCL_24_11188__EXEC__1.pdf

L'injonction concerne uniquement Google et Cloudflare (en plus des gros FAI français), pas les autres résolveurs alternatifs.

Il me semble que cette analyse loupe un point critique sur ce genre de systèmes : le fait que le serveur bitwarden vient avec un client web installé au même endroit que la BDD (si j'en crois cette image tirée de la documentation. L'attaquant qui contrôle le serveur peut modifier le client web et servir un code JS qui, en plus de dériver le mot de passe pour déchiffrer le coffre, pourrait l'envoyer à l'attaquant.

Ça compromet le mot de passe de tous ceux qui utilisent le client web pendant que l'attaquant contrôle le serveur. Ceux qui utilisent uniquement les clients lourds sont à l'abri, tant qu'ils ne téléchargent pas le client depuis le serveur compromis.

L'article se concentre uniquement sur les conséquences d'une fuite de données du serveur, par exemple si la BDD ou une sauvegarde est accédée par l'attaquant.

J'ai jamais pensé à l'utiliser pour LUKS, si tu as de l'expérience là-dessus ou des liens vers de la doc, je suis preneur.

J'ai rédigé un tutoriel ici même sur l'utilisation de clé GPG pour déchiffrer / avec luks sous Debian, utilisant cryptsetup-keyscripts (cf. d'autres exemples pour différentes possibilités).

C'est aussi possible en utilisant systemd-boot, comme l'évoque cg ci-dessus.

C'est à l'auteur de ce journal que je demande de faire cette vérification parce que je pense qu'il a commis une grosse erreur dans l'emballement de la découverte de ce problème.

Tu as raison. J'avais simplement vérifié que cups tournait avec les droits root et j'en avais déduit, trop rapidement, que les commandes ainsi injectées s'exécutaient avec ces privilèges. Ce n'est pas ce que montre la vidéo postée par Simone, le fichier malveillant appartient à lp.

Donc en l'état, ça permet une exécution de code en tant que lp, pas en tant que root. L'impact semble dès lors plus limité.

Est-ce qu'un modérateur peut éditer le journal initial ? Je propose de remplacer le deuxième paragraphe par :

Plusieurs failles de sécurité ont été publiées concernant le serveur d'impression Linux CUPS et des logiciels qui y sont liés. Combinées, elles permettent à un utilisateur distant de faire exécuter du code en tant que rootlp lors d'une impression initiée par un utilisateur du système. En particulier, elle permet donc à un utilisateur local de devenir root par ce biais. [EDIT : retrait de la mention d'élévation de privilège vers root].

Pouvez-vous en même temps modifier le titre en : "Faille d'exécution de code à distance / élévation de privilège dans cups" ?

Merci.

J'oubliais l'essentiel. Inutile de désactiver un service qui peut être utile.

J'adopte le principe inverse : inutile d'activer un service dont je ne suis pas certain de l'utilité (relativement à mes cas d'usage).

Typiquement, dans ce cas : je n'ai qu'une imprimante, branchée en USB sur mon poste, je n'ai pas besoin de ce service. Autant le désactiver (quitte à le réactiver temporairement, un jour, si je pense que ça simplifiera la configuration d'une nouvelle imprimante réseau).

Le soucis, c'est que la distribution doit prendre une décision pour tout le monde. L'arbitrage entre facilité d'utilisation ("l'utilisateur n'a rien à faire, tout va fonctionner") et position défensive ("rien n'est installé ni activé par défaut, l'utilisateur doit explicitement demander ce dont il a besoin") est très complexe.

En France, la Dinum subventionne (un peu) les logiciels libres via les prix blue hats : La mission logiciels libres (DINUM) propose 4 prix BlueHats de 10000€ pour soutenir des mainteneurs, mais les nominations sont closes.

L'article est faux sur plusieurs points :

• les passkeys ne nécessitent pas d'authentification biométrique
• ce n'est pas l'authentification biométrique qui permet le "chiffrement" et "l'infalsibialité" de l'authentification, c'est l'usage de clés privées détenues par un périphérique utilisateur dédiées à chaque service (l'accès à ces clés pouvant être protégé par le périphérique par une vérification biométrique)

Je me suis arrêté au premier paragraphe.

Idée de "truc" sur le réseau qui permette à la machine de démarrer : le couple clevis (côté client, qui doit déchiffrer) / tang (côté "serveur", sans lequel le client ne peut pas démarrer automatiquement).

L'avantage, par rapport à d'autres solutions, c'est que tang (le serveur) n'a pas la clé. Il a juste un élément indispensable pour que clevis puisse reconstruire la clé de son côté. Si ta machine a été volée, il suffit d'éteindre tang ou de le rendre inaccessible à clevis pour que le déchiffrement n'ait plus lieu.

Note : au moins dispo sur Debian et Fedora a priori, probablement dispo sur d'autres distributions Linux.

Sur l'attaque, Ledger a publié une explication sur son blog. Si j'ai bien compris :

• en règle générale, le code est relu et signé avant déploiement
• mais cette règle ne s'appliquait pas sur le dépôt NPMJS interne contenant les dépendances de certains codes créés par Ledger
• en règle générale, les accès des employés partis sont révoqués
• mais au moins un ancien employé avait toujours des accès actifs
• cet employé a été victime de phishing
• les attaquants ont utilisé cet accès pour pousser du code sur le dépôt NPMJS insuffisamment protégé
• ce code est appelé par les applications web qui interagissent avec le porte-feuille matériel (wallet)
• le code d'attaque faisait transférer les fonds du wallet vers un porte-feuille contrôlé par l'attaquant
• ce code serait resté actif 2h environ

C'est encore une faille liée à la chaîne d'approvisionnement logiciel, mais cette fois-ci via un dépôt interne. Cette attaque est soigneusement ciblée, chapeau aux attaquants. Elle a été très rapidement contre-carrée, chapeau aux défenseurs.

Est-ce que ça contourne le bridage de commandes si tu fais : ssh -J bastion bastion

Non : la première connexion au bastion fonctionne, mais la seconde tente d'ouvrir un shell et elle ne peut pas, elle échoue.

Enfin, je me demande comment ça se passe si la clé sur le bastion a besoin d'un déverrouillage via Smartcard ou Yubikey justement.

Je ne comprends pas la situation que tu as en tête. "la clé sur le bastion" = la clé publique autorisée à se connecter, celle présente dans authorized_keys ? Ou une clé privée permettant de se connecter à un serveur cible ?

Dans tous les cas, si tu as une clé qui demande une confirmation physique pour chaque utilisation, elle ne peut pas être utilisée sans ton accord par l'agent SSH même en cas de forwarding d'agent sur le bastion. Cependant, le bastion peut tout de même utiliser toutes les clés auxquelles l'agent a accès pour se connecter ailleurs, donc ça reste une situation risquée. À moins de n'avoir que des clés stockées sur des yubikey et soumises à confirmation, auquel cas l'agent ne sert à rien.

Bref, je ne vois pas de situation où le forwarding d'agent serait une bonne idée.

L'interception s'est faite en déroutant le trafic destiné au serveur vers un intermédiaire malveillant qui, du coup, a pu obtenir un certificat TLS valide via let's encrypt. Ça correspond à ce que propose le produit Jupiter, proposé par Nexa et vendu comme un logiciel d'interception légale (j'en parlais ici il y a quelques jours).

On note que les intercepteurs ont fait une petite boulette en oubliant de renouveller leur certificat a temps, ce qui a permis à l'administrateur système de détecter le problème.

Comme ils le notent en conclusion, la surveillance des journaux certificate transparency (cf. journal précédemment cité) aurait permis à l'administrateur de repérer le problème plus tôt. Ils notent aussi qu'on peut aussi demander à let's encrypt, via le DNS, de limiter la délivrance de certificats à un compte let's encrypt bien précis, de façon à empêcher l'attaque.

Le seul cas serait si la boite est mise devant ton IP publique mais a ce niveau il y a beaucoup de choses de corrompues.

C'est justement ce qui est fait ici : Jupiter est vendu à des États ou autorités militaires, et il est bien précisé que le site servant pour l'infection doit être "domestique", c'est-à-dire physiquement hébergé sur le territoire contrôlé par l'autorité client de l'Alliance Intellexa.

En effet, c'est une situation où "beaucoup de choses sont corrompues". Le but de ce journal est de signaler que même dans le cas où l'État fait partie de votre modèle de menace, TLS et Certificate Transparency fournissent des outils pour vous défendre.

Cependant le gestionnaire d'identité numérique sait qu'un site XXX l'a interrogé pour savoir si j'ai plus de 18 ans non ?

Non, le principe du double-anonymat doit te garantir que celui qui connait ton identité et donne une preuve "cette personne a plus de 18 ans" ne connait pas le destinataire de l'attestation (tu es anonyme vis-à-vis du site que tu veux visiter - modulo ta majorité ou non - et les sites que tu veux visiter ne sont pas transmis à ceux qui te connaissent).

Après, il faut que les protocoles soient correctement implémentés et que les entités qui opèrent les 2 services (site que tu visites / garant de l'identité numérique) soient réellement indépendants.

Contrairement à ce que plusieurs ont affirmé ici, utiliser httpS n'empêche pas totalement au FAI de deviner les pages que vous consultez : en faisant une analyse statistique de la taille des requêtes envoyées et reçues et les différences de temps entre les différentes requêtes, et en comparant ça au contenu du site web visité et au graphe de lien entre les pages, il peut "deviner" quelles pages vous avez visité. Selon les sites, cette attaque fonctionnera plus ou moins bien :

• ça ne fonctionnera pas pour google.com, facebook.com
• ça fonctionnera bien pour linuxfr.org, wikipedia.org, etc.

En revanche, les petites données que vous envoyez (mot de passe, code de carte bancaire …) ne seront pas devinables par l'attaquant.

Cette attaque est décrite dans Analysing user behaviors despite encryption sur le blog rabexc.org.

L'application est incroyablement défaillante, à un niveau difficilement inimaginable (je vous laisse lire l'article).

Le plus incroyable, c'est leur réponse au "responsible disclosure" de l'auteur de l'article : « "How were you able to decompile the source code of the app and what do you think should be done to protect against that in the future?" ».

"Deploy web apps anywhere" me fait plutôt penser à redbean, encore plus portable! (et incroyablement plus léger).

Bonjour,

Ton besoin me fait penser à mailcow. Je n'ai jamais testé, donc je ne connais pas la qualité du produit.

C'est ce qu'indique la doc. man ssh_config :

IdentityFile

[…] The default is ~/.ssh/id_rsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ecdsa_sk, ~/.ssh/id_ed25519, ~/.ssh/id_ed25519_sk and ~/.ssh/id_dsa

C'est beaucoup plus large que la configuration SSH, mais les recommandations de sécurité relatives à un système GNU/Linux proposées par l'Anssi (agence de l'État français pour la sécurité informatique) ont plein de recommandations chouettes, et classent les 80 recommandations en 4 niveaux de durcissement (minimal, intermédiaire, renforcé et élevé).

HS : Sur le port knocking comme méthode d'authentification, j'avais lu (en anglais) quelqu'un qui expliquait que ça revenait à encoder un mot de passe, éventuellement tournant (façon TOTP ou HOTP) sous forme d'une suite d'octets, et que pour gérer ça on avait rudement plus efficace que le port knocking, dans les protocoles eux-mêmes (= les modes d'authentification à clé publique proposée par SSH, ou par mot de passe pour certaines applications - mots de passe auxquels il convient de donner la longueur adéquate, cela va de soi). Je ne retrouve plus la source, si quelqu'un me lit et l'a sous le coude, je suis preneur !

(note : le commentaire cité dans l'article parle du port knocking comme d'une méthode ayant pour effet de limiter le bruit dans les logs, pas comme d'une mesure apportant une sécurité supplémentaire … donc la remarque au paragraphe précédent ne s'y oppose pas).

Si tu RSSI te force à changer de mot de passe, c'est :

1. soit que tu as un compte à privilèges
2. soit qu'il est en retard sur les recommandations de l'Anssi. La nouvelle politique préconisée en matière de mot de passe (donc après la mise en place d'authentification forte ou à plusieurs facteurs), c'est :
   • renouvellement régulier des mots de passe pour les comptes d'administration
   • renouvellement d'un mot de passe utilisateur en cas de suspicion de compromission (piratage du poste ou d'un serveur, mot de passe entré au mauvais endroit, …)