Posté par octane .
En réponse au message Blogs?.
Évalué à 2.
De recette, il n'y en a point :-(
Vous vous en doutez fort, le sujet qui m'intéresse n'est pas les pates à la violette, c'était juste une tentative d'humour pour ne pas avoir à expliciter le sujet de mon blog (inintéressant pour 99.973% de la population mondiale). Et cette histoire de pâtes à la violette m'ayant beaucoup fait rire, je la ressors régulièrement :D
Posté par octane .
En réponse au message Blogs?.
Évalué à 2.
Je t'offre toute ma considération \o/
Par contre, le numéro de page me parait fort surprenant, c'est de la BD franco-belge classique de 48 pages, à moins qu'il ne s'agisse d'une intégrale contenant plusieurs tomes.
Globalement, tu indiques que le critère de comparaison entre l'homme et la machine n'est jamais défini. C'est vrai. Comme disait quelqu'un, l'homme se considère supérieur à l'animal car il a un cerveau évolué. Si on avait choisi l'estomac comme organe différenciateur, la vache serait au sommet du règne animal. Coup de chance, c'est l'homme qui choisit l'échelle de comparaison, et il choisit un critère bénéfique pour lui :D
L'exemple du calcul est intéressant aussi. Dans le temps, il y avait des "calculateurs", des personnes chargées de faire les calculs dans les labos de recherche. C'était une profession estimée, et considérée très intelligente. Deux circuits de silicium plus tard et l'invention de la calculette, ils ont été mis au placard, complètements écrasés par la puissance de la machine. Et sans parler de silicium, pensons aux ânes de traits qui se sont vus totalement explosés par la puissance d'un camion pour porter une charge.
La machine, supérieure à l'homme? On trouvera toujours quelque chose. Pendant longtemps, on disait que le jour ou la machine battra l'homme aux échecs, ça sera la fin (de quoi exactement on sait pas trop), puis la machine a battu l'homme et on a dit que le critère était mauvais. In fine l'homme utilise la machine pour étudier ses parties et trouver des nouvelles méthodes de jeu. L'homme joue toujours aux échecs :-)
Pour les maths, il y aura sûrement des avancées par l'IA, et puis? Le métier de matheux évoluera sans doute, est-ce qu'il disparaitra complètement, c'est pas dit. Et dans le domaine artistique, ça bouge pas mal car on le pensait inimaginable. C'est très intéressant à suivre.
Du coup, je suis assez d'accord avec ta conclusion : "l'IA deviendra-t-elle « supérieure » aux humains ? La question n'a pas de sens : l'IA s'améliorera certainement selon certains critères, comme produire des textes toujours plus élaborés, mais ces critères eux-mêmes sont anthropomorphes, ils sont choisis d'après ce qui est humain" mais j'ajouterai que l'humain choisira toujours un domaine ou il se sentira supérieur, alors qu'il suffirait simplement de dire que l'IA est "différente" à la manière où l'on ne compare le tonnage d'un camion avec celui d'un âne bâté.
Posté par octane .
En réponse au message Blogs?.
Évalué à 2.
L'histoire des pâtes à la violette est tirée d'un Achille Talon. J'offre toute ma considération à celui (ou celle) qui trouve le titre de la bande dessinée :-)
J'ai essayé avec Android x86 mais ça ne marche pas avec la plupart des applis privatrices :-(
Sans doute qu'ils ne fournissent pas les binaires x86 :-) Les applis bien faites empaquètent le java (universel) + les libs native en arm/arm64/x86/x86_64 (c'est d'ailleurs ce qui est compilé par défaut).
Les applis moins gentilles compilent les libs natives en arm64 et c'est tout. (gain de temps à la compile? Gain de stockage? Gait de bande passante? je sais pas trop)
de mémoire l'émulation arm/arm64 est d'une lenteur abominable. Tu lances l'émulateur, ton PC mouline tant qu'il peut, ça boote toooooout doucement et avec un peu de malchance tu as un message d'android lui même qui te dit "oulala, je met des heures à booter, sp'a normal, je kill tous les process et je reboote allez bye".
L'émulation x86_64 est honorable (car elle utilise les instrus de virtualisation de ton CPU).
Posté par octane .
En réponse au message Carte IA.
Évalué à 3.
La réponse est en deux points, tout d'abord le fait de faire tourner des IA sur ton PC bureau, et sur l'entraînement de modèles.
Je m'amuse avec des LLM locaux depuis quelques temps, sans CG. J'ai juste pris mon CPU, ollama fonctionne simplement avec. Le facteur limitant, c'est la RAM. Tu regardes le nombre de paramètres de ton modèle (genre 13B) et c'est la quantité en Go de RAM dont tu as besoin (ce calcul est simpliste et faux, mais c'est une approximation facile à faire et suffisante).
Ca va ramer (ne t'attends pas à aller aussi vite que sur les sites web), mais c'est suffisant pour tester. J'ai des résultats intéressants pour m'aider à coder et sur la génération de texte. Le problème c'est que les "petits" modèles (genre 7B, 13B, 24B) sont loin de la qualité des chatGPT/mistralAI que tu trouves gratuits, donc l'avantage d'un LLM local reste mitigé.
Pour l'entraînement, je ne sais pas duquel tu parles: soit de générer ton modèle, et apparemment c'est hors de portée du commun des mortels (genre faut des fermes entières de PC+CG), soit il s'agit d'extension du contexte.
Par exemple, tu donnes à ton LLM local un corpus de pdf sur ton disque et tu lui poses des questions dessus et ça, c'est possible localement en CPU only (mais ça rame + que de la question/réponse de base). Je suis justement en train d'affiner des paramètres et des méthodes de contexte pour éviter d'une part les hallucinations et d'autre part les réponse hors-contexte (genre il n'y a pas la réponse dans les pdfs, le LLM doit me dire qu'il ne sait pas au lieu d'essayer d'inventer un truc).
Mais est ce que ça tourne souvent avec de la glibc et openssh ?
Pour raspbian, oui.
Pour les autres, la proba reste faible je dirais. Souvent l'embarqué c'est du dropbear (ou pas de serveur ssh du tout). Donc oui, ça reste assez minime.
J'ai le sentiment que plus grand monde n'a de machines 32 bits intel, donc ça limite un peu la portée aussi.
Je n'ai pas relu le papier de qualys, mais il me semble que ça impacte le 32bits de manière générale? Il a pris i386, mais ça serait la même chose sur ARM, powerPc ou mips?
Et de l'arm32 il en reste pas mal (y'a un paquet de raspberryPi par exemple, car le site propose toujours du 32bits). Mips32 aussi.
Alors oui, il y a des contournements, oui, l'exploit est long. Mais ça reste une p*tain de vulnérabilités. Ouais, c'est ssh, c'est bien codé, y'a de la défense en profondeur mais ça reste exceptionnel.
Et pour l'ASLR, c'est pas vraiment aussi mélangé que l'on croit. Tiens, par exemple, en 32 bits, il y a exactement 2 adresses pour la glibc (si si, 2, ce n'est pas une typo).
```
Moreover, this Debian version suffers from the ASLR weakness described
in the following great blog posts (by Justin Miller and Mathias Krause,
respectively):
Concretely, in the case of sshd on i386, every memory mapping is
randomized normally (sshd's PIE, the heap, most libraries, the stack),
but the glibc itself is always mapped either at address 0xb7200000 or at
address 0xb7400000; in other words, we can correctly guess the glibc's
address half of the time
```
Est-ce que ça fonctionne ? Parfois oui, parfois non. Ça fonctionne jusque’à ce que quelqu’un trouve le secret ! Auquel cas la sécurité disparait totalement s’il est rendu public.
Bah imaginons un code. Tu l'obscurcis. Quelqu'un le désobscurcit. La sécurité revient au niveau initial. Donc la sécurité n'est pas nulle… Imaginons que je prenne ssh, j'en fais une version propriétaire, sans code source. Je compile et diffuse les binaires. Si tu l'analyses et tu la reverses, est-ce que la sécurité est nulle lorsque tu te rends compte que le code source est lisible?
Ce qui est surprenant, c'est que dans la suite tu dis toi même que le port knocking c'est de l'obscurité, mais que si quelqu'un le dévoile alors la sécurité est toujours présente (ssh)…
Est-ce une bonne idée ? Non, bien évidemment. C’est d’ailleurs un excellent argument pour les logiciels libres et Open Source, la disponibilité du code permettant de l’auditer.
ah bah, cf libzlma, xz, Jia Tan et tout. Le code était public et c'est finalement en black box que le bug a été découvert. Au delà d'un niveau de complexité, closed source == open source. Et le kernel est incroyablement complexe.
Les failles de certains protocoles réseaux, certains logiciels et certains systèmes d’exploitation, notamment Windows dans ses grandes heures, sont un exemple concret des dégâts qui peuvent être causés quand l’éditeur ou le concepteurs mentent sur le niveau de sécurité de leur produit ou pire, cachent volontairement les failles.
C'est la même chose pour tous les logiciels? Une faille c'est catastrophique, et microsoft je crois pas qu'ils cachent des failles (?)
Le port knocking, ça aurait protégé si la tentative de backdoor via liblzma avait réussi, ou en cas de 0-day sur openssh.
Je suis pas convaincu. un 0-day sur openssh, c'est comme le dahu, on en parle on en a jamais vu. S'il existait, je pense que personne ne s'amuserait à aller exploiter le serveur d'un lecteur de linuxfr. Il irait taper des vraies cibles qui lui ramèneraient de l'argent/de l'information.
Pour lzma, même chose, les cibles auraient été connues et soit c'est un service vaguement public (genre bastion d'entreprise) et là, la séquence de port knock est connue, soit c'est une cible vraiment visée et je pense que l'attaquant prend le temps d'écouter ce qu'il faut pour trouver le port knocking…
Je pense que son succès vient de fait que ça fait peur aux gens de voir qu'ils ont des tentatives de connexions SSH.
C'est surtout qu'auditer des journaux remplis de connexions bidons, c'est juste pénible, ça fait perdre du temps.
Avoir un vrai message d'alerte, c'est intéressant.
(bon, moi j'ai mis mon port ssh sur un port improbable, genre pas 22, ni 2222, ni 2022, etc.. et j'ai plus de logs donc je suis content aussi :) )
Le vieux Lyon.
Prendre la ficelle pour monter à Fourvière, redescendre par les théatres gallo-romains.
Se promener sur les quais de rhône et remonter jusqu'au parc de la tête d'Or.
Faire les traboules de la croix-rousse.
Manger dans un bouchon.
Eventuellement prendre une carte velo'v, c'est + sympa que le bus.
Posté par octane .
En réponse au journal Linuxfr sous les drapeaux.
Évalué à 5.
Dernière modification le 18 juin 2024 à 15:04.
(LL et LGBT+) Si je conçois qu'on puisse appuyer les deux,
bah du coup, je crois que tu as compris pourquoi il y a un drapeau. Je pense qu'il faut pas chercher forcément plus loin.
Quelque part, ces vers résonnent en moi. Un drapeau sert à regrouper les partisans d'un bloc politique, et laisse peu de place à la pensée indépendante. Les drapeaux ont souvent servi à dresser des peuples les uns contre les autres, à cristalliser ou à justifier une contre-révolution en cours, à symboliser la mainmise d'un groupe sur un pays, enfin, c'est un concept qui ne m'est pas très sympathique.
Tu n'aimes pas les drapeaux, sauf le drapeau noir. Mais c'est un drapeau. Après, c'est un symbole (comme le pingouin), ce n'est pas forcément un symbole guerrier.
Bref, s'il fallait voter, je serais plutôt partisan de voter pour le maintien du drapeau.
Je ne sais pas si c'est possible, mais j'aimerai un LLM et pouvoir lui dire:
MOI: "tiens, vla mon /var/log/messages (ou mon journalct --no-tail), lis moi tout ça, et extrait moi des informations pertinentes"
LLM: "Bien sûr, j'ai constaté de multiples tentatives de connexions ssh et des messages smartctl"
MOI: "oublie les connexions ssh, donne moi le message smartclt"
LLM: "le message indique que le disque secondaire du système est en train de mourir"
MOI: "donne moi les commandes pour sauvegarder le disque"
LLM: …
Voilà un peu ce que j'aimerai que les LLM fassent. Faire des greps, je sais faire. Lire un journal aussi. Doit y'avoir moyen de faire manger ça à un LLM pour qu'il corrèle un peu les données?
Il s'agit là de l'API technique actuelle. Il n'y a pas de raison de ne pas faire générer ces XML autrement voir si une solution devient fondamentalement meilleure de la rendre native. À mon avis c'est le fait de ne pas s'en servir qui fait que ça n'est pas amélioré. Je suis pour la pratique qui consiste à dire que si quelque chose est compliqué, il faut le faire plus souvent. Plus fréquemment on fait les choses, plus on va se débrouiller pour l'améliorer.
Je suis pas forcément convaincu de cette approche. On peut justifier à peu près tout, et j'ai déjà vu ça dans des projets de dev. Un dev "influent" va pousser une vague solution à un vague problème qu'il rencontre, et fait face à de la résistance. du coup, les managers utilisent cet argument: "si vous râlez, c'est que vous l'utilisez pas, on va forcer l'usage, et la simplicité viendra". Et ensuite, bah certains devs poussent des rustines, contournent le problème, et le dev influent est content, il dit que sa solution est la meilleure!
C'est tjs un peu pareil : "olalala, c'est trop complexe, je vais faire ça plus simple. step1: un cas unique qui couvre mes besoins. step2: on augmente et on couvre 95% des besoins. step3: on ajoute pleins de cas particuliers. step4: c'est devenu trètrètrècompliqué didon!" rinse and repeat. Il y a un step3 aussi: "vos cas particuliers ne seront pas traités, modifiez tout pour coller à mon cas d'usage que j'ai défini. Pliez vous y ou dégagez, c'est du LL, libre à toi de tout redev dans ton coin".
bah, tu ouvres un bug. Genre "l'image jointe fait crasher la libimage quand j'essaye de l'ouvrir".
Ca fait du sens de pouvoir attacher des PJ. Ou alors: "voici le crashlog de 4.5Mo que j'ai mis en PJ plutôt que de le copier/coller en texte brute dans le bugreport".
Et bien évidemment, ça fait du sens de le copier dans le repo dest. Sinon, tu ouvres un bug, tu fermes ton compte, et le dev a un beau rapport de bug avec une pièce jointe qui a disparu…
Je suis surpris par le mot "faille". Ce n'est pas une faille, c'est un détournement malveillant d'un service légitime. Parler de faille, c'est un peu pompeux?
Comme si je disais "des hackers profitent d'une faille technique de Peugeot pour aller braquer une banque" (oui, ils sont allés en voiture à la banque).
La backdoor était sous la forme de code binaire caché dans les données de test, donc il n'y a que le .o pour le moment. Je ne doute pas que dans quelque jours, quelqu'un va coller le dump en assembleur avec une analyse. Il y a 87 ko de code compilé, avec du code existant, donc ça doit pas être non plus trop gros.
Alors. Avoir le dump assembleur, c'est très simple. On fait un coup de objdump -d et hop.
Ou pas.
Ca démarre pas très bien :(
liblzma_la_crc64_fast_o: format de fichier elf64-x86-64
Déassemblage de la section .text.x86_codd :
0000000000000000 <.Lx86_code.part.0>:
0: f3 0f 1e fa endbr64
4: 41 54 push %r12
6: b9 02 00 00 00 mov $0x2,%ecx
b: 49 89 f4 mov %rsi,%r12
e: be 12 00 00 00 mov $0x12,%esi
13: 55 push %rbp
14: 48 89 d5 mov %rdx,%rbp
17: ba 46 00 00 00 mov $0x46,%edx
1c: 53 push %rbx
1d: 48 89 fb mov %rdi,%rbx
20: 31 ff xor %edi,%edi
22: 48 83 ec 20 sub $0x20,%rsp
26: e8 00 00 00 00 call 2b <.Lx86_code.part.0+0x2b>
2b: 85 c0 test %eax,%eax
code à l'adresse 0. Et toutes les fonctions sont comme ça:
Déassemblage de la section .text.lzma_block_buffer_encoda :
0000000000000000 <.Llzma_block_buffer_encode.0>:
0: f3 0f 1e fa endbr64
4: 48 29 fe sub %rdi,%rsi
7: c7 44 24 f8 e2 05 00 movl $0x5e2,-0x8(%rsp)
e: 00
f: 89 d0 mov %edx,%eax
(...)
Déassemblage de la section .text.lzma_raw_coder_memusaga :
0000000000000000 <.text.lzma_raw_coder_memusaga>:
0: 55 push %rbp
1: 49 89 f8 mov %rdi,%r8
(...)
Déassemblage de la section .text.lzma2_encoder_inia :
0000000000000000 <.Llzma2_encoder_init.1>:
0: f3 0f 1e fa endbr64
4: 41 57 push %r15
(vous avez noté que toutes les fonctions ont remplacé leur dernière lettre par un 'a' ?)
Bref. Allons voir du côté des relocations du coup.
$ readelf -rW infected_lib.so
Section de réadressage '.rela.text.x86_codd' à l'adresse de décalage 0xe2e8 contient 7 entrées :
Décalage Info Type Valeurs symbols Noms symboles + Addenda
0000000000000027 0000007900000004 R_X86_64_PLT32 0000000000000000 .Llzma2_decoder_end.1 - 4
000000000000020a 0000001c00000002 R_X86_64_PC32 0000000000000000 .rodata.BRANCH_TABLE0 + 1c
000000000000032f 0000001c00000002 R_X86_64_PC32 0000000000000000 .rodata.BRANCH_TABLE0 - 4
00000000000003ee 0000001b00000002 R_X86_64_PC32 0000000000000000 .rodata.MASK_TO_BIT_NUMBER0 + 5c
0000000000000494 0000001b00000002 R_X86_64_PC32 0000000000000000 .rodata.MASK_TO_BIT_NUMBER0 + 3c
0000000000000515 0000001b00000002 R_X86_64_PC32 0000000000000000 .rodata.MASK_TO_BIT_NUMBER0 + 1c
000000000000053c 0000001b00000002 R_X86_64_PC32 0000000000000000 .rodata.MASK_TO_BIT_NUMBER0 - 4
Section de réadressage '.rela.text.lzma_raw_coder_memusaga' à l'adresse de décalage 0xe390 contient 2 entrées :
Décalage Info Type Valeurs symbols Noms symboles + Addenda
0000000000000016 0000003800000004 R_X86_64_PLT32 0000000000000000 .Llzma_block_buffer_encode.0 - 4
000000000000004a 0000008600000004 R_X86_64_PLT32 0000000000000000 .Lx86_code.part.0 - 4
Section de réadressage '.rela.text.lzma2_encoder_inia' à l'adresse de décalage 0xe3c0 contient 4 entrées :
Décalage Info Type Valeurs symbols Noms symboles + Addenda
0000000000000060 0000000100000002 R_X86_64_PC32 0000000000000000 .text.lzma_raw_coder_memusaga - 4
LOL PTDR! C'est un véritable challenge, là. Juste à comprendre ce que tu reloges ou pas. J'ai jamais vu ça. Du coup, je comprends mieux les gens qui ne donnent pas une analyse. Rien que reconstruire le vrai binaire, c'est un truc de gueudin. Je préfère aller boire un coup et attendre que quelqu'un le fasse, haha
Nulle part je ne trouve une analyse du code de la backdoor?
Alors on, ça cible les fonctions RSA de sshd donc on se doute que la backdoor permet un bypass de l'authentification, mais est-ce que quelqu'un a extrait le code et fait une analyse complète ?
[^] # Re: Pâtes à la violette
Posté par octane . En réponse au message Blogs?. Évalué à 2.
De recette, il n'y en a point :-(
Vous vous en doutez fort, le sujet qui m'intéresse n'est pas les pates à la violette, c'était juste une tentative d'humour pour ne pas avoir à expliciter le sujet de mon blog (inintéressant pour 99.973% de la population mondiale). Et cette histoire de pâtes à la violette m'ayant beaucoup fait rire, je la ressors régulièrement :D
[^] # Re: Pâtes à la violette
Posté par octane . En réponse au message Blogs?. Évalué à 2.
Je t'offre toute ma considération \o/
Par contre, le numéro de page me parait fort surprenant, c'est de la BD franco-belge classique de 48 pages, à moins qu'il ne s'agisse d'une intégrale contenant plusieurs tomes.
# intéressant
Posté par octane . En réponse au lien [Blog] Sur la question « Quand l'intelligence artificielle dépassera-t-elle les humains ? ». Évalué à 5.
Globalement, tu indiques que le critère de comparaison entre l'homme et la machine n'est jamais défini. C'est vrai. Comme disait quelqu'un, l'homme se considère supérieur à l'animal car il a un cerveau évolué. Si on avait choisi l'estomac comme organe différenciateur, la vache serait au sommet du règne animal. Coup de chance, c'est l'homme qui choisit l'échelle de comparaison, et il choisit un critère bénéfique pour lui :D
L'exemple du calcul est intéressant aussi. Dans le temps, il y avait des "calculateurs", des personnes chargées de faire les calculs dans les labos de recherche. C'était une profession estimée, et considérée très intelligente. Deux circuits de silicium plus tard et l'invention de la calculette, ils ont été mis au placard, complètements écrasés par la puissance de la machine. Et sans parler de silicium, pensons aux ânes de traits qui se sont vus totalement explosés par la puissance d'un camion pour porter une charge.
La machine, supérieure à l'homme? On trouvera toujours quelque chose. Pendant longtemps, on disait que le jour ou la machine battra l'homme aux échecs, ça sera la fin (de quoi exactement on sait pas trop), puis la machine a battu l'homme et on a dit que le critère était mauvais. In fine l'homme utilise la machine pour étudier ses parties et trouver des nouvelles méthodes de jeu. L'homme joue toujours aux échecs :-)
Pour les maths, il y aura sûrement des avancées par l'IA, et puis? Le métier de matheux évoluera sans doute, est-ce qu'il disparaitra complètement, c'est pas dit. Et dans le domaine artistique, ça bouge pas mal car on le pensait inimaginable. C'est très intéressant à suivre.
Du coup, je suis assez d'accord avec ta conclusion : "l'IA deviendra-t-elle « supérieure » aux humains ? La question n'a pas de sens : l'IA s'améliorera certainement selon certains critères, comme produire des textes toujours plus élaborés, mais ces critères eux-mêmes sont anthropomorphes, ils sont choisis d'après ce qui est humain" mais j'ajouterai que l'humain choisira toujours un domaine ou il se sentira supérieur, alors qu'il suffirait simplement de dire que l'IA est "différente" à la manière où l'on ne compare le tonnage d'un camion avec celui d'un âne bâté.
[^] # Re: Pâtes à la violette
Posté par octane . En réponse au message Blogs?. Évalué à 2.
L'histoire des pâtes à la violette est tirée d'un Achille Talon. J'offre toute ma considération à celui (ou celle) qui trouve le titre de la bande dessinée :-)
[^] # Re: Suggestions pragmatiques
Posté par octane . En réponse au journal France Connect Plusse. Évalué à 4.
Sans doute qu'ils ne fournissent pas les binaires x86 :-) Les applis bien faites empaquètent le java (universel) + les libs native en arm/arm64/x86/x86_64 (c'est d'ailleurs ce qui est compilé par défaut).
Les applis moins gentilles compilent les libs natives en arm64 et c'est tout. (gain de temps à la compile? Gain de stockage? Gait de bande passante? je sais pas trop)
[^] # Re: Suggestions pragmatiques
Posté par octane . En réponse au journal France Connect Plusse. Évalué à 5.
de mémoire l'émulation arm/arm64 est d'une lenteur abominable. Tu lances l'émulateur, ton PC mouline tant qu'il peut, ça boote toooooout doucement et avec un peu de malchance tu as un message d'android lui même qui te dit "oulala, je met des heures à booter, sp'a normal, je kill tous les process et je reboote allez bye".
L'émulation x86_64 est honorable (car elle utilise les instrus de virtualisation de ton CPU).
# et avec le CPU?
Posté par octane . En réponse au message Carte IA. Évalué à 3.
La réponse est en deux points, tout d'abord le fait de faire tourner des IA sur ton PC bureau, et sur l'entraînement de modèles.
Je m'amuse avec des LLM locaux depuis quelques temps, sans CG. J'ai juste pris mon CPU, ollama fonctionne simplement avec. Le facteur limitant, c'est la RAM. Tu regardes le nombre de paramètres de ton modèle (genre 13B) et c'est la quantité en Go de RAM dont tu as besoin (ce calcul est simpliste et faux, mais c'est une approximation facile à faire et suffisante).
Ca va ramer (ne t'attends pas à aller aussi vite que sur les sites web), mais c'est suffisant pour tester. J'ai des résultats intéressants pour m'aider à coder et sur la génération de texte. Le problème c'est que les "petits" modèles (genre 7B, 13B, 24B) sont loin de la qualité des chatGPT/mistralAI que tu trouves gratuits, donc l'avantage d'un LLM local reste mitigé.
Pour l'entraînement, je ne sais pas duquel tu parles: soit de générer ton modèle, et apparemment c'est hors de portée du commun des mortels (genre faut des fermes entières de PC+CG), soit il s'agit d'extension du contexte.
Par exemple, tu donnes à ton LLM local un corpus de pdf sur ton disque et tu lui poses des questions dessus et ça, c'est possible localement en CPU only (mais ça rame + que de la question/réponse de base). Je suis justement en train d'affiner des paramètres et des méthodes de contexte pour éviter d'une part les hallucinations et d'autre part les réponse hors-contexte (genre il n'y a pas la réponse dans les pdfs, le LLM doit me dire qu'il ne sait pas au lieu d'essayer d'inventer un truc).
[^] # Re: Faut aussi voir les versions
Posté par octane . En réponse au journal Alerte rouge! RCE dans opensshd. Évalué à 3.
Pour raspbian, oui.
Pour les autres, la proba reste faible je dirais. Souvent l'embarqué c'est du dropbear (ou pas de serveur ssh du tout). Donc oui, ça reste assez minime.
[^] # Re: Faut aussi voir les versions
Posté par octane . En réponse au journal Alerte rouge! RCE dans opensshd. Évalué à 2.
Je n'ai pas relu le papier de qualys, mais il me semble que ça impacte le 32bits de manière générale? Il a pris i386, mais ça serait la même chose sur ARM, powerPc ou mips?
Et de l'arm32 il en reste pas mal (y'a un paquet de raspberryPi par exemple, car le site propose toujours du 32bits). Mips32 aussi.
[^] # Re: Faut aussi voir les versions
Posté par octane . En réponse au journal Alerte rouge! RCE dans opensshd. Évalué à 6.
Alors oui, il y a des contournements, oui, l'exploit est long. Mais ça reste une p*tain de vulnérabilités. Ouais, c'est ssh, c'est bien codé, y'a de la défense en profondeur mais ça reste exceptionnel.
Et pour l'ASLR, c'est pas vraiment aussi mélangé que l'on croit. Tiens, par exemple, en 32 bits, il y a exactement 2 adresses pour la glibc (si si, 2, ce n'est pas une typo).
```
Moreover, this Debian version suffers from the ASLR weakness described
in the following great blog posts (by Justin Miller and Mathias Krause,
respectively):
https://zolutal.github.io/aslrnt/
https://grsecurity.net/toolchain_necromancy_past_mistakes_haunting_aslr
Concretely, in the case of sshd on i386, every memory mapping is
randomized normally (sshd's PIE, the heap, most libraries, the stack),
but the glibc itself is always mapped either at address 0xb7200000 or at
address 0xb7400000; in other words, we can correctly guess the glibc's
address half of the time
```
[^] # Re: Secret bien gardé
Posté par octane . En réponse au journal Les toqueurs ont la tactique . Évalué à 3.
eh bin certains matins je ferais mieux de me taire :(
https://www.openwall.com/lists/oss-security/2024/07/01/3
# Au sujet de l'obscurité
Posté par octane . En réponse au journal Les toqueurs ont la tactique . Évalué à 3.
Bah imaginons un code. Tu l'obscurcis. Quelqu'un le désobscurcit. La sécurité revient au niveau initial. Donc la sécurité n'est pas nulle… Imaginons que je prenne ssh, j'en fais une version propriétaire, sans code source. Je compile et diffuse les binaires. Si tu l'analyses et tu la reverses, est-ce que la sécurité est nulle lorsque tu te rends compte que le code source est lisible?
Ce qui est surprenant, c'est que dans la suite tu dis toi même que le port knocking c'est de l'obscurité, mais que si quelqu'un le dévoile alors la sécurité est toujours présente (ssh)…
ah bah, cf libzlma, xz, Jia Tan et tout. Le code était public et c'est finalement en black box que le bug a été découvert. Au delà d'un niveau de complexité, closed source == open source. Et le kernel est incroyablement complexe.
C'est la même chose pour tous les logiciels? Une faille c'est catastrophique, et microsoft je crois pas qu'ils cachent des failles (?)
[^] # Re: Secret bien gardé
Posté par octane . En réponse au journal Les toqueurs ont la tactique . Évalué à 3.
Je suis pas convaincu. un 0-day sur openssh, c'est comme le dahu, on en parle on en a jamais vu. S'il existait, je pense que personne ne s'amuserait à aller exploiter le serveur d'un lecteur de linuxfr. Il irait taper des vraies cibles qui lui ramèneraient de l'argent/de l'information.
Pour lzma, même chose, les cibles auraient été connues et soit c'est un service vaguement public (genre bastion d'entreprise) et là, la séquence de port knock est connue, soit c'est une cible vraiment visée et je pense que l'attaquant prend le temps d'écouter ce qu'il faut pour trouver le port knocking…
[^] # Re: Secret bien gardé
Posté par octane . En réponse au journal Les toqueurs ont la tactique . Évalué à 3.
C'est surtout qu'auditer des journaux remplis de connexions bidons, c'est juste pénible, ça fait perdre du temps.
Avoir un vrai message d'alerte, c'est intéressant.
(bon, moi j'ai mis mon port ssh sur un port improbable, genre pas 22, ni 2222, ni 2022, etc.. et j'ai plus de logs donc je suis content aussi :) )
[^] # Re: pas sur d'être de bon conseil, mais
Posté par octane . En réponse au message Que voir à Lyon ?. Évalué à 4.
suivi de
alors si je ne m'abuse, le mur des lyonnais c'est quai de Saone, justement :D
Sinon, +1 pour les conseils
# pas sur d'être de bon conseil, mais
Posté par octane . En réponse au message Que voir à Lyon ?. Évalué à 8.
Le vieux Lyon.
Prendre la ficelle pour monter à Fourvière, redescendre par les théatres gallo-romains.
Se promener sur les quais de rhône et remonter jusqu'au parc de la tête d'Or.
Faire les traboules de la croix-rousse.
Manger dans un bouchon.
Eventuellement prendre une carte velo'v, c'est + sympa que le bus.
# ouais
Posté par octane . En réponse au journal Linuxfr sous les drapeaux. Évalué à 5. Dernière modification le 18 juin 2024 à 15:04.
bah du coup, je crois que tu as compris pourquoi il y a un drapeau. Je pense qu'il faut pas chercher forcément plus loin.
Tu n'aimes pas les drapeaux, sauf le drapeau noir. Mais c'est un drapeau. Après, c'est un symbole (comme le pingouin), ce n'est pas forcément un symbole guerrier.
Bref, s'il fallait voter, je serais plutôt partisan de voter pour le maintien du drapeau.
[^] # Re: L'apprentissage des logs ?
Posté par octane . En réponse au journal LLM auto-hébergés ou non : mon expérience. Évalué à 3.
Je ne sais pas si c'est possible, mais j'aimerai un LLM et pouvoir lui dire:
MOI: "tiens, vla mon /var/log/messages (ou mon journalct --no-tail), lis moi tout ça, et extrait moi des informations pertinentes"
LLM: "Bien sûr, j'ai constaté de multiples tentatives de connexions ssh et des messages smartctl"
MOI: "oublie les connexions ssh, donne moi le message smartclt"
LLM: "le message indique que le disque secondaire du système est en train de mourir"
MOI: "donne moi les commandes pour sauvegarder le disque"
LLM: …
Voilà un peu ce que j'aimerai que les LLM fassent. Faire des greps, je sais faire. Lire un journal aussi. Doit y'avoir moyen de faire manger ça à un LLM pour qu'il corrèle un peu les données?
[^] # Re: Deltachat ?
Posté par octane . En réponse au message Messagerie smartphone <-> linux. Évalué à 4.
Alors je n'avais pas testé deltachat, mais ça a l'air carrément bien en fait :o
Ca ressemble très très fort à ce que je voulais faire, sauf que c'est déjà fait \o/
merci beaucoup, je m'en vais tester ça
[^] # Re: Conf Polkit pour remplacer sudo
Posté par octane . En réponse au lien Lennart veut remplacer sudo par run0 dans SystemD. Évalué à 9.
Je suis pas forcément convaincu de cette approche. On peut justifier à peu près tout, et j'ai déjà vu ça dans des projets de dev. Un dev "influent" va pousser une vague solution à un vague problème qu'il rencontre, et fait face à de la résistance. du coup, les managers utilisent cet argument: "si vous râlez, c'est que vous l'utilisez pas, on va forcer l'usage, et la simplicité viendra". Et ensuite, bah certains devs poussent des rustines, contournent le problème, et le dev influent est content, il dit que sa solution est la meilleure!
C'est tjs un peu pareil : "olalala, c'est trop complexe, je vais faire ça plus simple. step1: un cas unique qui couvre mes besoins. step2: on augmente et on couvre 95% des besoins. step3: on ajoute pleins de cas particuliers. step4: c'est devenu trètrètrècompliqué didon!" rinse and repeat. Il y a un step3 aussi: "vos cas particuliers ne seront pas traités, modifiez tout pour coller à mon cas d'usage que j'ai défini. Pliez vous y ou dégagez, c'est du LL, libre à toi de tout redev dans ton coin".
[^] # Re: faille?
Posté par octane . En réponse au lien Des hackers profitent d'une faille technique de GitHub pour diffuser leur malware. Évalué à 4.
bah, tu ouvres un bug. Genre "l'image jointe fait crasher la libimage quand j'essaye de l'ouvrir".
Ca fait du sens de pouvoir attacher des PJ. Ou alors: "voici le crashlog de 4.5Mo que j'ai mis en PJ plutôt que de le copier/coller en texte brute dans le bugreport".
Et bien évidemment, ça fait du sens de le copier dans le repo dest. Sinon, tu ouvres un bug, tu fermes ton compte, et le dev a un beau rapport de bug avec une pièce jointe qui a disparu…
# faille?
Posté par octane . En réponse au lien Des hackers profitent d'une faille technique de GitHub pour diffuser leur malware. Évalué à 6.
Je suis surpris par le mot "faille". Ce n'est pas une faille, c'est un détournement malveillant d'un service légitime. Parler de faille, c'est un peu pompeux?
Comme si je disais "des hackers profitent d'une faille technique de Peugeot pour aller braquer une banque" (oui, ils sont allés en voiture à la banque).
[^] # Re: Le code de la backdoor?
Posté par octane . En réponse au lien Backdoor in upstream xz/liblzma leading to ssh server compromise. Évalué à 4.
https://gist.github.com/smx-smx/a6112d54777845d389bd7126d6e9f504
donne plus d'infos.
Eeeeet globalement, on s'en fiche de ces reloc. Un outil comme IDA râle un peu, mais finit par ouvrir le binaire, donc c'est bon.
[^] # Re: Le code de la backdoor?
Posté par octane . En réponse au lien Backdoor in upstream xz/liblzma leading to ssh server compromise. Évalué à 5.
Alors. Avoir le dump assembleur, c'est très simple. On fait un coup de objdump -d et hop.
Ou pas.
Ca démarre pas très bien :(
code à l'adresse 0. Et toutes les fonctions sont comme ça:
(vous avez noté que toutes les fonctions ont remplacé leur dernière lettre par un 'a' ?)
Bref. Allons voir du côté des relocations du coup.
LOL PTDR! C'est un véritable challenge, là. Juste à comprendre ce que tu reloges ou pas. J'ai jamais vu ça. Du coup, je comprends mieux les gens qui ne donnent pas une analyse. Rien que reconstruire le vrai binaire, c'est un truc de gueudin. Je préfère aller boire un coup et attendre que quelqu'un le fasse, haha
# Le code de la backdoor?
Posté par octane . En réponse au lien Backdoor in upstream xz/liblzma leading to ssh server compromise. Évalué à 5.
Nulle part je ne trouve une analyse du code de la backdoor?
Alors on, ça cible les fonctions RSA de sshd donc on se doute que la backdoor permet un bypass de l'authentification, mais est-ce que quelqu'un a extrait le code et fait une analyse complète ?