Bonjour Nal,
certains jours, des certitudes disparaissent. Par exemple, le résultat aux élections, ou des softs qu'on pensait durs comme l'acier. Mais certains matins sont plus douloureux que d'autres. Et ce matin, entre autre, j'ai lu qu'openssh est vulnérable! (cris, hurlements, grincements de dents, etc..).
Et oui, certains chercheurs en sécu ont réussi l'impensable: ils possèdent une RCE sur opensshd. Et c'est grave.
Avant de courir les bras en l'air en disant 'onoz' ou d'arracher les cables RJ45 des datacenters, quelques précisions:
- l'attaque fonctionne sur i386, le chercheur pense que c'est exploitable en x86_64 mais ne l'a pas codé.
- la vuln touche les systèmes linux basé sur glibc
- une mise à jour existe, go go go update!
https://www.openwall.com/lists/oss-security/2024/07/01/3
https://www.openssh.com/security.html
avant de jeter openssh, je copie colle la note préliminaire de l'advisory:
Preliminary note: OpenSSH is one of the most secure software in the
world; this vulnerability is one slip-up in an otherwise near-flawless
implementation. Its defense-in-depth design and code are a model and an
inspiration, and we thank OpenSSH's developers for their exemplary work.
Je vous laisse, j'ai des distribs à update, see you!
# La faille en 1 phrase
Posté par Mimoza . Évalué à 7.
Extrait de https://www.openssh.com/security.html
Traduit rapidement ça donne :
Le point qui a attiré mon attention est «sur des système non-OpenBSD».
[^] # Re: La faille en 1 phrase
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 4.
L'article sur openwall explique assez bien le pourquoi du comment. En gros la faille est inactivée sur openBSD depuis 2001 grâce à des appels systèmes "thread safe" par défaut, et était patchée en interne dans OpenSSH depuis 2006 avant d'avoir été réintroduite par inadvertance. L'article d'OpenWall est d'ailleurs assez bien construit : il se divise en section de plus en plus technique ce qui le rend partiellement très accessible même pour un ignorant.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: La faille en 1 phrase
Posté par gUI (Mastodon) . Évalué à 6.
C'est quoi cette mention "Portable" ? C'est celle qu'on a généralement dans les distribs ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: La faille en 1 phrase
Posté par 101010 . Évalué à 10.
La version native est celle d'OpenBSD.
La version portable est celle pour les autres systèmes d'exploitation.
# Faut aussi voir les versions
Posté par Misc (site web personnel) . Évalué à 10.
Déja, faut des versions assez récentes (par exemple, ni RHEL 7 ou RHEL 8), l'attaque est longue (de 1 mois à quelques heures), et n'a été testé que sur des machines avec un réseau fiable (même si ça concerne sans doute tout les serveurs).
Je ne sais pas non plus comment se comporte l'exploit avec un serveur qui est utilisé donc avec du CPU à fond, ou des utilisateurs qui font des ssh (genre, est ce que les bots qui scannent tout l'internet vont foutre la zone dans les mesures de timing précises ?)
Ensuite, y a des contournements plus simples que mettre GraceLoginTime à 0 comme "relancer openssh toutes les heures". C'est con, mais vu que ça va changer le layout en mémoire, ça remets l'ASLR à 0.
Je me demande aussi si avoir openssh en "start on demand", comme sur certains systèmes embarqués ou comme Ubuntu 22.10 n'a pas aussi le bon goût de foutre en l'air l'exploit (vu qu'avec un process séparé à chaque fois, c'est dur de trouver les offsets mélangés par par l'ASLR)
[^] # Re: Faut aussi voir les versions
Posté par octane . É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: Faut aussi voir les versions
Posté par Misc (site web personnel) . Évalué à 4.
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 ne dit pas qu'il y a pas moyen a terme de contourner l'ASLR sur le 64 bits, mais c'est aussi plus difficile. Donc il y a quand même le temps de voir venir.
Ceci dit, ayant lu plus en détail l'advisory, je vois que ma question sur "est ce que les bots influent sur le timing" a pour réponse "sans doute pas suffisamment". Sur ma machine, ssh lance 1 process par connexion, et je suppose que c'est ce process qui est attaqué, donc un bot va juste ralentir l'attaque en prenant un slot de MaxProcesses de temps en temps, donc ralentir de 10 à 20 % au maximum l'attaque, ce qui est négligeable vu le temps que ça prends déjà (genre, au lieu de 8h, ça va en prendre 1 de plus).
[^] # Re: Faut aussi voir les versions
Posté par orfenor . Évalué à 5.
les distros qui continuent de sortir en 32 bits ont visiblement un sentiment différent — et des stats de téléchargement :-)
[^] # Re: Faut aussi voir les versions
Posté par Misc (site web personnel) . Évalué à 4.
Certes, mais est ce que c'est des machines avec un serveur ssh et une connexion fiable ?
Des discussions que j'ai vu sur les listes Fedora, c'était surtout des gens avec des vieux PCs de bureau. C'est certes fonctionnel, mais je ne crois pas que ça soit la cible de ce genre d'exploit (car j'ai des doutes sur l'usage de ssh dessus, et surtout des doutes sur la connexion fiable, en plus d'avoir des doutes sur la valeur des infos qu'on peut obtenir).
Je suis sur qu'une grande majorité des serveurs encore sous garantie sont en 64 bits, et que même si plein de gens ont des vieux trucs hors garantie pour du test, c'est aussi du 64 bits.
Y a du 32 bits dans l'embarqué, je n'en doute pas, mais est ce que c'est de l'intel, est ce qu'il y a un ssh exposé ?
[^] # Re: Faut aussi voir les versions
Posté par cluxter . Évalué à 1.
À ce propos, quelles sont les distributions qui existent encore en 32 bits ? J'ai eu besoin d'en utiliser une en 2020 pendant le Covid et j'ai été surpris de voir que ce n'était pas si simple à trouver que ça. J'étais bien content d'avoir une vieille version d'Ubuntu 32 bits gravée sur un vieux CD-Rom (si si) avec un lecteur CD en USB, ça m'a rapidement sorti de la panade.
[^] # Re: Faut aussi voir les versions
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 5.
Mageia existe en 32bits, j'imagine que SlackWare aussi.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Faut aussi voir les versions
Posté par BAud (site web personnel) . Évalué à 4. Dernière modification le 19 août 2024 à 20:29.
et Debian, Emmabuntüs, PrimTux
ainsi que Gentoo
et quelques autres ;-)
[^] # Re: Faut aussi voir les versions
Posté par octane . É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 Misc (site web personnel) . Évalué à 4.
Mais est ce que ça tourne souvent avec de la glibc et openssh ?
Je concède qu'il y a sans doute des tas de gens avec de la raspbian qui traînent (même si je suppose pas trop dans un cadre professionnel business critical), mais pas forcément exposé sur internet directement. Et pour mips32, j'aurais tendance à croire que c'est de l'openwrt, avec dropbear et un libc autre que la glibc.
C'est peut être aussi exploitable, mais sans doute après un temps important de développement (> 1 mois) comme x86_64.
[^] # Re: Faut aussi voir les versions
Posté par octane . É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.
# Fedora est-il impacté ?
Posté par Yuul B. Alwright . Évalué à 5.
La faille est annoncée publiquement, mais avant que tout le monde ai pu faire la mise à jour ?
Sur des serveurs tournant sous Fedora Server que je dois gérer, la version d'OpenSSH semble être concernée.
Mais j'ai rien trouvé d'autres que ce ticket :
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2024-6387
Sur les salons IRC de Fedora, sur Libera.chat, c'est trop silencieux.
Le dernier build d'OpenSSH sur koji build system date du 23 juin.
Donc en attendant, arrêt de tout les services
sshd, on ressort le cables UART et je vais devoir me déplacer. :([^] # Workaround
Posté par 101010 . Évalué à 2. Dernière modification le 01 juillet 2024 à 19:39.
Plutôt que de débrancher les câbles…
Source : équipe FreeBSD
[^] # Re: Workaround
Posté par Misc (site web personnel) . Évalué à 4.
Sinon, on peut aussi se dire que la création d'un exploit sur 64 bits va sans doute prendre quelques jours ou semaines (on sait que Qualys est dessus depuis ~1 ou 2 mois vu qu'ils ont contactés l'équipe openssh dés qu'ils ont commencés à bosser sur l'exploit 64 bits:
Soit avant:
J'imagine que Qualys ne va pas coller l'exploit partout (pas plus qu'ils ont collé l'exploit pour le 32 bits), et que donc les attaquant vont devoir repartir de 0. De plus, comme indiqué également dans l'advisory, l'ASLR sur 64 bits rends l'écriture d'un exploit plus difficile.
Tout ça pour dire qu'il y a sans doute pas de quoi paniquer (au sens "faut tout interrompre", mais que faire une mise à jour demain ou après demain (quand le paquet sera sur les miroirs), ça sera sans doute largement suffisant.
En fait, je suis même pas sur que grand monde se jette dans le développement d'un exploit de ce genre vu qu'il va vite être patcher. Prendre 1 ou 2 mois pour un usage certes puissant mais sans doute peu applicable car beaucoup de gens vont naturellement mettre à jour n'est pas forcément un bon calcul (car les boites/agences/gang qui écrivent les outils d'exploitation, elles ont aussi des contraintes de rentabilité de leur temps)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.