in risposta a Hacker News...

Vedo che voi burloni su [il sito arancione][hn] mi state dando filo da torcere. Farò alcune risposte scelte qui sotto, ma prima offro una sfida: invierò 500$ di tasca mia alla prima persona che riesca a dimostrare questo attacco senza ifunc. Sono sinceramente interessato, e disposto a pagare per l'illuminazione. Fai un fork di questo repo e invia una PR con il tuo PoC funzionante, ti chiederò privatamente il tuo indirizzo postale se vinci. Ora le risposte:

Stai abbaiando all'albero sbagliato.

Ragazzo, io vivo nell'albero sbagliato, posso abbaiare a chi voglio.

Non era essenziale per l'exploit,

Tu non sei essenziale per l'exploit!

C'è sempre selinux se vogliamo aggiungere protezione contro codice arbitrario in esecuzione come root.

Una volta caricato, questo attacco non aveva bisogno di attraversare ulteriori confini di syscall. Quindi sì, avremmo potuto limitare una sessione root "bonus", ma avremmo comunque avuto ospiti indesiderati sulla macchina!

Cos'è questo, il compleanno di Bilbo?? Nessun ingresso se non per affari della festa!!

1. IFUNC non è certo l'unico modo per eseguire codice prima di main.

Ma è un modo non necessario per eseguire codice prima che la protezione della memoria sia impostata

2. L'alternativa che presentano è probabilmente meno sicura perché il puntatore alla funzione rimarrà scrivibile per tutta la vita del processo,

Possiamo improvvisare con mprotect! Vedi l'ultima frase sopra la sottosezione Modifying LD_PRELOAD.

Sì, questo blog è fuorviante.

Scusami questo blog era senza guida. Ho fatto tutti questi imbrogli da solo! Nessuno mi ha ingannato per farmi diventare così stupido.

IFUNC dovrebbe essere implementato dal software [client] stesso,

@CountWSS 💯 diavolo sì

una serie di evidenti fallimenti di processo da parte del manutentore di Github attraverso ...

Questo è l'unico punto a cui risponderò seriamente:

Penso che sia straordinariamente ingiusto verso il manutentore di xz-utils e piuttosto pericoloso per la comunità pensare a questo come iniziato con un suo errore. È iniziato con nessuno che si preoccupava di aiutare a mantenere questo progetto. L'attaccante si è affidato a ifunc come vulnerabilità tecnica e alla nostra negligenza collettiva di xz-utils come vulnerabilità sociale. Penso che sia vergognoso vedere le azioni del signor Collin come qualcosa di diverso da una dedizione eroica, durata anni, al servizio della comunità.

Inoltre Bruce Schneier è d'accordo con me quindi... peccato per te, il tuo argomento è toast.

Il linguaggio potrebbe essere stato più duro del necessario

Non crederai a quanto i miei amici mi hanno fatto annacquare tutto questo prima.

Le distribuzioni Linux non dovrebbero pensare così tanto a se stesse da aspettarsi che OpenBSD si conformi e si adatti al loro disordine

@debazel!!! Me gusta.

Che completa stronzata.

Okay, quella parte è accurata.

IFUNC'd up

Perché dovresti smettere di incolpare xz-utils per [CVE-2024-3094][nvd]. Inoltre dai un'occhiata al mio ETSA Talk!

CVE-2024-3094, più comunemente noto come "Il backdoor di xz-utils", è stato un quasi disastro per la cybersecurity globale. Se questo attacco non fosse stato scoperto appena in tempo da [Andres Freund][freund], la maggior parte dei server SSH del nostro pianeta avrebbe iniziato a concedere accesso root alla parte dietro questo attacco.

Sfortunatamente, troppa analisi si è concentrata su come [codice malevolo][JiaT75] si sia fatto strada nel repo di xz-utils. Invece, vorrei sostenere che due decisioni di progettazione di lunga data in software open source critico sono ciò che ha reso possibile questo attacco: [collegare OpenSSH contro SystemD][biebl], e l'esistenza di [GNU IFUNC][sourceware].

Prima di Iniziare: Gran parte di questa discussione tratta le complessità del linking dinamico su Linux. Se hai bisogno di un ripasso, dai un'occhiata a dynamic_linking.md.

Breve Riassunto di CVE-2024-3094

Ci sono tantissime buone analisi che delineano i dettagli di alto livello del backdoor di xz-utils, come [What we know about the xz Utils backdoor that almost infected the world][goodin1] di Dan Goodin e il gist [FAQ on the xz-utils backdoor (CVE-2024-3094)][thesamesam] di Sam James. Non abbiamo bisogno di ripetere tutto qui, quindi per gli scopi di questo articolo, ecco un molto approssimativo riassunto:

• Alcune distro Linux modificano OpenSSH per dipendere da SystemD
• SystemD dipende da xz-utils, che usa GNU IFUNC
• Ergo, xz-utils finisce nello spazio di indirizzamento di OpenSSH
• Questo permette a ifunc di modificare il codice nel server SSH```mermaid flowchart TD G["GNU IFUNC"] A["OpenSSH (OpenBSD)"] B["Portable OpenSSH
  (Linux / macOS / etc)"] C[OpenSSH + IFUNC] D[xz-utils] E["SystemD (Linux)"] A -->|Remove OpenBSD specifics| B B -->|Add SystemD specifics| C D --> E E --> C C --> F["Mayhem"] G --> D

## Perché le distribuzioni Linux modificano OpenSSH?
La risposta breve è che devono farlo. OpenSSH è sviluppato dalla
comunità OpenBSD, per la comunità OpenBSD, e non gliene importa
niente di Linux. Il progetto [Portable OpenSSH][mindrot] è una
raccolta best-effort di patch che sostituiscono i componenti specifici di
OpenBSD con componenti POSIX generici, e con codice specifico per
piattaforma dove applicabile. La catena di fornitura del software per SSH
finisce per assomigliare a qualcosa del genere nella pratica:```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 versione di OpenSSH di OpenBSD è a monte di tutto il resto, e la maggior parte dei miglioramenti proviene dalla comunità OpenBSD. Queste modifiche fluiscono a valle verso il progetto Portable OpenSSH, che tenta di re-implementare le nuove funzionalità in modi che non siano specifici per OpenBSD. Questo è ciò che permette a SSH di funzionare su piattaforme come Linux, macOS, FreeBSD e persino Windows.

Ma non finisce qui. Alcuni sistemi operativi applicano ulteriori personalizzazioni oltre a quelle fornite da Portable OpenSSH. Ad esempio, Apple aggiunge il flag [--apple-use-keychain][keith] a ssh-add per aiutarlo a integrarsi con il gestore di password di macOS.

Nel caso di CVE-2024-3094, Fedora e Debian mantenevano le proprie [patch SystemD][biebl] per i loro fork di OpenSSH al fine di correggere una [race condition relativa ai riavvii di sshd][schmidt]. Quindi la effettiva supply chain per SSH iniziò a somigliare a questo:```mermaid flowchart TD A[OpenSSH] B[Portable OpenSSH] C[Debian SSH] D[Fedora SSH] A-->B B-->C B-->D C<-->|SystemD Patches|D

Questi patch non sono mai entrati in Portable OpenSSH, perché le
persone di Portable OpenSSH non erano ["interessate ad assumere una
dipendenza da libsystemd"][djmdjm]. E non sono mai entrati in upstream
OpenSSH, perché OpenBSD non ha alcuna necessità di supportare SystemD.