robertdfrench/ifuncd-upGNU IFUNC est le véritable responsable derrière CVE-2024-3094
Je vois que vous, les plaisantins de [le site orange][hn], me donnez du fil à retordre. Je vais faire quelques réponses choisies ci-dessous, mais d'abord je lance un défi : j'enverrai 500 $ de mon propre argent à la première personne qui pourra démontrer cette attaque sans ifunc. Je suis sincèrement intéressé, et prêt à payer pour l'illumination. Forkez ce dépôt et soumettez une PR avec votre PoC fonctionnel, je vous demanderai votre adresse postale en privé si vous gagnez. Maintenant, les réponses :
C'est s'attaquer au mauvais arbre.
Petit, je vis dans le mauvais arbre, je peux aboyer après qui je veux.
Ce n'était pas essentiel à l'exploit,
Toi, tu n'es pas essentiel à l'exploit !
Il y a toujours selinux si on veut ajouter une protection contre l'exécution de code arbitraire en tant que root.
Une fois chargée, cette attaque n'avait pas besoin de franchir d'autres frontières d'appels système. Donc oui, on aurait pu contraindre une session root « bonus », mais on aurait quand même eu des invités indésirables sur la machine !
C'est quoi, l'anniversaire de Bilbo ?? Pas d'entrée sauf pour affaires de fête !!
- IFUNC n'est de loin pas le seul moyen d'exécuter du code avant main.
Mais c'est un moyen inutile d'exécuter du code avant que la protection mémoire ne soit mise en place
- L'alternative qu'ils présentent est sans doute moins sûre parce que le pointeur de fonction restera accessible en écriture pendant toute la durée de vie du processus,
On peut improviser avec mprotect ! Voir la dernière phrase au-dessus de la sous-section Modifying LD_PRELOAD.
Ouais, ce blog est à côté de la plaque.
Excusez-moi, ce blog était sans guide. J'ai fait toutes ces manigances moi-même ! Personne ne m'a poussé à être aussi stupide.
IFUNC devrait être implémenté par [le client] logiciel lui-même,
@CountWSS 💯 carrément ouais
une série d'échecs de processus flagrants de la part du mainteneur Github jusqu'à ...
C'est le seul point auquel je répondrai sérieusement :
Je pense qu'il est extrêmement injuste envers le mainteneur de xz-utils et assez dangereux pour la communauté de penser que cela a commencé par une erreur de sa part. Cela a commencé parce que personne n'en avait rien à foutre d'aider à maintenir ce projet. L'attaquant a utilisé ifunc comme vulnérabilité technique et notre négligence collective de xz-utils comme vulnérabilité sociale. Je trouve honteux de voir les actions de M. Collin comme autre chose qu'un dévouement héroïque de plusieurs années au service de la communauté.
De plus Bruce Schneier est d'accord avec moi donc... désolé pour toi, ton argument est grillé.
Le langage a peut-être été plus dur que nécessaire
Tu ne vas pas croire à quel point mes amis m'ont forcé à l'adoucir d'abord.
Les distributions Linux ne devraient pas s'estimer au point d'attendre d'OpenBSD qu'il se conforme et s'adapte à leur bordel
@debazel !!! Me gusta.
Quelle connerie totale.
Bon, cette partie est exacte.
Pourquoi vous devriez arrêter de blâmer xz-utils pour [CVE-2024-3094][nvd]. Jetez aussi un œil à ma conférence ETSA !
CVE-2024-3094, plus communément appelé « la porte dérobée de xz-utils », a été un quasi-accident pour la cybersécurité mondiale. Si cette attaque n'avait pas été découverte juste à temps par [Andres Freund][freund], la plupart des serveurs SSH de notre planète auraient commencé à accorder un accès root à la partie derrière cette attaque.
Malheureusement, trop d'analyses se sont concentrées sur la manière dont le [code malveillant][JiaT75] s'est frayé un chemin dans le dépôt xz-utils. Je voudrais plutôt soutenir que deux décisions de conception de longue date dans des logiciels open source critiques sont ce qui a rendu cette attaque possible : [lier OpenSSH contre SystemD][biebl], et l'existence de [GNU IFUNC][sourceware].
Avant de commencer : Une grande partie de cette discussion traite des subtilités de l'édition de liens dynamique sous Linux. Si vous avez besoin d'un rappel, consultez dynamic_linking.md.
Il existe des tonnes de bons articles décrivant les détails de haut niveau de la porte dérobée xz-utils, comme [What we know about the xz Utils backdoor that almost infected the world][goodin1] de Dan Goodin et le gist [FAQ on the xz-utils backdoor (CVE-2024-3094)][thesamesam] de Sam James. Nous n'avons pas besoin de tout répéter ici, donc pour les besoins de cet article, voici un récapitulatif très grossier :
## Pourquoi les distributions Linux modifient-elles OpenSSH ?
La réponse courte est qu'elles y sont obligées. OpenSSH est développé par
la communauté OpenBSD, pour la communauté OpenBSD, et ils se fichent
royalement de Linux. Le projet [Portable OpenSSH][mindrot] est une
collection de patches au mieux de leurs capacités qui remplacent les
composants spécifiques à OpenBSD par des composants POSIX génériques, et
du code spécifique à certaines plateformes le cas échéant. La chaîne
d'approvisionnement logicielle pour SSH finit par ressembler à quelque
chose comme ceci en pratique :```mermaid
flowchart TD
subgraph OpenBSD Folks
A[OpenBSD]
B[OpenSSH]
H[improvements]
end
B-->A
A-->H
H-->B
B-->C
C[Portable OpenSSH]
subgraph Debian Folks
D[Debian SSH]
G[improvements]
end
C-->D
D-->G
G-->C
subgraph Fedora Folks
J[Fedora SSH]
K[improvements]
end
C-->J
J-->K
K-->C
La version d'OpenSSH d'OpenBSD est en amont de tout le reste, et la plupart des améliorations qui y sont apportées proviennent de la communauté OpenBSD. Ces changements se propagent en aval vers le projet Portable OpenSSH, qui tente de réimplémenter les nouvelles fonctionnalités d'une manière qui ne soit pas spécifique à OpenBSD. C'est ce qui permet à SSH de fonctionner sur des plateformes comme Linux, macOS, FreeBSD, et même Windows.
Mais cela ne s'arrête pas là. Certains systèmes d'exploitation appliquent une personnalisation supplémentaire au-delà de ce que fournit Portable OpenSSH. Par exemple, Apple ajoute le drapeau [--apple-use-keychain][keith] à ssh-add pour faciliter son intégration avec le gestionnaire de mots de passe de macOS.