[00:21:16]
<m606> hmm, et si tu sauvegardes la config actuelle dans le panneau de configuration de l'app dans l'admin YNH, est-ce que le `True` est toujours là? Il devrait pas https://github.com/YunoHost-Apps/onlyoffice_ynh/blob/75f2fe84a696ac688fe305ae7064f67b260228f7/scripts/config#L26, mais alors peut-être un souci dans la question d'install.
[01:01:10]
<Aleks (he/him/il/lui)> Ça ressemble à un bug dans la gestion des booleens dans les configs panels en general
[08:12:38]
<rodinux> Les bind true ou false ??
[09:32:48]
<rodinux> Ça semble corrigé en tous les cas...
[12:57:54]
<pti-jean> [CVE-2026-31431] IMPORTANT: upgrade your system package :
https://forum.yunohost.org/t/cve-2026-31431-important-upgrade-your-system-package/42171
Je ne vois pas l'intérêt de corriger cette faille sur Yunohost, car on peut faire "sudo su" sans mot de passe... Du coup cela perd tout son intérêt! Non ??
[12:59:39]
<florent> Tes apps sont exécutées avec un utilisateur dédié pour chaque, pour les isoler du système.
Donc si, c'est important.
[13:00:15]
<florent> C'est pas un environnement docker, mais il y a un peu de sandboxing et du hardening systemd
[13:01:04]
<florent> Bref, mieux vos pas traîner et corriger dans tous les cas que de justifier pourquoi c'est pas important selon moi.
[13:01:15]
<florent> Bref, mieux vaut pas traîner et corriger dans tous les cas que de justifier pourquoi c'est pas important selon moi.
[13:02:34]
<pti-jean> Je ne comprend pas... Il faut avoir accès au shell pour activé la faille... et si tu accèdes au shell, tu peux faire un "sudu su" ??
[13:03:05]
<pti-jean> Je ne comprend pas... Il faut avoir accès au shell pour activé la faille... et si tu accèdes au shell, tu peux faire un "sudo su" ??
[13:05:08]
<florent> Je n'ai pas lu qu'il était requis d'avoir accès à un shell.
[13:05:37]
<florent> Après n'oublie pas qu'il y a des personnes qui proposent aussi Yunohost à des utilisateurs, qui ont de fait accès à la machine sans accès root (`sudo su` n'est possible que pour les gens du groupe admin)
[13:06:06]
<pti-jean> https://xint.io/blog/copy-fail-linux-distributions
[13:08:11]
<pti-jean> Plutôt ce lien:
https://copy.fail/
[13:14:22]
<pti-jean> Mais chez moi, si je suis pas du groupe admin... je ne peux pas me connecter en ssh! Je viens de faire le test!
[13:14:47]
<pti-jean> Du coup, quel intérêt ??
[13:15:35]
<artlogmatrix> pti-jean cette faille permet de remplacer n'importe quel binaire par une autre, certes 4 octets à la fois mais au total cela veut dire que tu peux exectuer ce que tu veux, s'il y a un programme setuid alors il suffira de rle rempaler et ton injection aura les droits root.
[13:15:36]
<artlogmatrix> cela rend toute injection de code foutrement dangereuse et réduit à néant tout le confirnement par droits utilisateurs.
[13:17:47]
<pti-jean> Mais par quelle méthode tu changes un binaire, sans avoir accès à la machine ?
[13:24:59]
<artlog> il n'y a pas que ssh pour exécuter du code à distance, il y a aussi d'autres failles potentielles.
[13:24:59]
<artlog> j'imagine que si ce genre de chose avait été révélé lors de log4shell (https://fr.wikipedia.org/wiki/Log4Shell) qui permettait lui d'executer du code arbitraire, alors on aurait eu le combo fatal
[13:25:00]
<artlog> je pars toujours du principe de ne pas réduire mes défenses, une faille c'est un trou dans un filtet de sécurité, ce n'est pjamais bon les trous dans les filets ...
[13:25:55]
<florent> Imagine, tu as une application qui contient une faille de sécurité grave (genre exécution de commande à distance ou communément appelé RCE).
Cette application est compromise.
L'intérêt de Yunohost est aussi de relever la sécurité pour éviter que cette compromission impacte trop le reste du système (avec le hardening de systemd). C'est un filet de sécurité.
Si par hasard il y a en plus cette faille de sécurité, et que l'attaquant l'exploite, il aura accès à l'entièreté de ta machine, ce qui n'est pas bon.
[13:28:12]
<florent> Enfin, bon, quand je vois cette faille, j'ai cette philosophie ⬆️
On passe généralement plus de temps à cogiter *à justifier pourquoi ne pas mettre à jour* (avec le risque de se tromper) plutôt que de mettre à jour.
[13:32:28]
<artlog> Les RCE c'est quelquechose , c'est presque une faiblesse fondamentale que je reliari à l'architecture von neuman ou le code est une donnée.
[13:32:30]
<artlog> ici le vecteur de RCE c'est git.
[13:32:30]
<artlog> Parfois ça laisse des traces : https://www.wiz.io/blog/github-rce-vulnerability-cve-2026-3854
[13:50:01]
<artlog> on ne va pas dire que github ce sont des neuneus en matière de scu
[13:50:01]
<artlog> sachant que la faille copy fail existe depuis 2017, le combo était parfaitement possible...
[13:50:02]
<artlog> imaginons cinq secondes que Grav soit installé sur yunohost pour fournir à une personne l'adminsitration du site grav, et justye l'adminsitration du site pas tout yunohost.
[13:50:02]
<artlog> et paf le chien https://advisories.gitlab.com/composer/getgrav/grav/CVE-2026-42607/
[14:06:03]
<artlog> biensûr on peut penser qu'en fournissant un grav à une personne externe on a confiance dans cette personne, mais quid si cette personne s'amuse avec openclaw ?
[16:24:21]
<pti-jean> Après YunoHost me propose comme mise à jour:
libgd3
libhashkit2
libmemcached11
et des:
php*
...
[16:24:39]
<pti-jean> Je ne vois pas de kernel...
[16:25:16]
<pti-jean> Donc, je crois pas que cela résoudra la faille !
[16:46:23]
<miro5001> Magnifique
[16:53:55]
<Thomas> Peux-tu réessayer après un nouvel upgrade vers la branche testing ?
[16:59:04]
<pti-jean> Heu testing... cela ne me bote pas!
[17:00:39]
<pti-jean> Comme je suis sur RPI... j'ai appliqué cette soluce:
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead 2>/dev/null || true
Le script :
https://github.com/rootsecdev/cve_2026_31431/blob/main/test_cve_2026_31431.py
me dit que c'est ok!