em resposta ao Hacker News...

Vejo vocês, piadistas do [site laranja][hn], me dando trabalho. Vou fazer algumas respostas escolhidas abaixo, mas primeiro ofereço um desafio: enviarei $500 do meu próprio dinheiro para a primeira pessoa que conseguir demonstrar este ataque sem ifunc. Estou genuinamente interessado, e disposto a pagar pelo esclarecimento. Faça um fork deste repositório e envie um PR com seu PoC funcional, solicitarei seu endereço postal em particular se você vencer. Agora, as respostas:

Isso é latir para a árvore errada.

Garoto, eu vivo na árvore errada, posso latir para quem eu quiser.

Não era essencial para o exploit,

Você não é essencial para o exploit!

Sempre há o selinux se quisermos adicionar proteção contra código arbitrário rodando como root.

Uma vez carregado, este ataque não precisou cruzar mais nenhuma fronteira de syscall. Então sim, poderíamos ter restringido uma sessão root "bônus", mas ainda teríamos tido convidados indesejados na máquina!

O que é isso, o aniversário do Bilbo?? Sem entrada exceto para assuntos da festa!!

1. IFUNC dificilmente é a única maneira de executar código antes do main.

Mas é uma maneira desnecessária de executar código antes que a proteção de memória seja configurada

2. A alternativa que eles apresentam é indiscutivelmente menos segura porque o ponteiro de função permanecerá gravável durante toda a vida do processo,

Podemos improvisar com mprotect! Veja a última frase acima da subseção Modificando LD_PRELOAD.

Sim, este blog está equivocado.

Com licença, este blog foi sem orientação. Eu fiz todas essas travessuras sozinho! Ninguém me enganou para ser tão estúpido.

IFUNC deveria ser implementado pelo próprio software [cliente],

@CountWSS 💯 isso aí

uma série de falhas flagrantes de processo do mantenedor do Github até ...

Este é o único ponto que vou responder com seriedade:

Acho extraordinariamente injusto com o mantenedor do xz-utils e bastante perigoso para a comunidade pensar nisso como começando com um erro da parte dele. Começou com ninguém dando a mínima para ajudar a manter este projeto. O atacante dependeu do ifunc como uma vulnerabilidade técnica e da nossa negligência coletiva do xz-utils como uma vulnerabilidade social. Acho vergonhoso ver as ações do Sr. Collin como qualquer coisa que não seja uma dedicação heroica de anos ao serviço comunitário.

Além disso, Bruce Schneier concorda comigo então... lamento por você, seu argumento está morto.

A linguagem pode ter sido mais dura do que precisava ser

Você não vai acreditar o quanto meus amigos me fizeram suavizar isso primeiro.

As distribuições Linux não deveriam se achar tão importantes a ponto de esperar que o OpenBSD se conforme e se adapte à bagunça delas

@debazel!!! Me gusta.

Que completa bobagem.

Ok, essa parte é precisa.

IFUNC'd up

Por que você deveria parar de culpar o xz-utils pela [CVE-2024-3094][nvd]. Também confira minha Palestra na ETSA!

A CVE-2024-3094, mais comumente conhecida como "O backdoor do xz-utils", foi um quase acidente para a cibersegurança global. Se este ataque não tivesse sido descoberto no último momento por [Andres Freund][freund], a maioria dos servidores SSH do nosso planeta teria começado a conceder acesso root ao grupo por trás deste ataque.

Infelizmente, muita análise se concentrou em como [código malicioso][JiaT75] chegou ao repositório do xz-utils. Em vez disso, gostaria de argumentar que duas decisões de design de longa data em software open source crítico são o que tornaram este ataque possível: [vincular o OpenSSH ao SystemD][biebl], e a existência do [GNU IFUNC][sourceware].

Antes de Começar: Muita desta discussão lida com as complexidades da vinculação dinâmica no Linux. Se você precisar de uma revisão, confira dynamic_linking.md.

Breve Recapitulação da CVE-2024-3094

Existem inúmeras boas análises descrevendo os detalhes de alto nível do backdoor do xz-utils, como [O que sabemos sobre o backdoor do xz Utils que quase infectou o mundo][goodin1] de Dan Goodin e o gist [FAQ sobre o backdoor do xz-utils (CVE-2024-3094)][thesamesam] de Sam James. Não precisamos repetir tudo isso aqui, então, para os propósitos deste artigo, aqui está uma recapitulação muito superficial:

• Algumas distros Linux modificam o OpenSSH para depender do SystemD
• O SystemD depende do xz-utils, que usa GNU IFUNC
• Logo, o xz-utils acaba no espaço de endereçamento do OpenSSH
• Isso permite que o ifunc modifique código no servidor 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

## Por que as distribuições Linux modificam o OpenSSH?
A resposta curta é que elas precisam. O OpenSSH é desenvolvido pela
comunidade OpenBSD, para a comunidade OpenBSD, e eles não dão a mínima
para o Linux. O projeto [Portable OpenSSH][mindrot] é uma
coletânea de patches, na medida do possível, que substitui componentes
específicos do OpenBSD por componentes POSIX genéricos, e algum código
específico de plataforma quando aplicável. A cadeia de suprimentos de software para SSH acaba se parecendo com algo assim na prática:```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

A versão do OpenSSH do OpenBSD é upstream de todo o resto, e a maioria das melhorias nele vem de dentro da comunidade OpenBSD. Essas mudanças fluem downstream para o projeto Portable OpenSSH, que tenta reimplementar novos recursos de formas que não sejam específicas do OpenBSD. Isso é o que permite que o SSH funcione em plataformas como Linux, macOS, FreeBSD e até Windows.

Mas não para por aí. Alguns sistemas operacionais aplicam ainda mais personalização além do que o Portable OpenSSH fornece. Por exemplo, a Apple adiciona a flag [--apple-use-keychain][keith] ao ssh-add para ajudá-lo a integrar-se com o gerenciador de senhas do macOS.

No caso do CVE-2024-3094, Fedora e Debian mantinham seus próprios [patches do SystemD][biebl] para seus forks do OpenSSH, a fim de corrigir uma [condição de corrida em torno de reinicializações do sshd][schmidt]. Então a verdadeira cadeia de suprimentos do SSH começou a se parecer com isto:```mermaid flowchart TD A[OpenSSH] B[Portable OpenSSH] C[Debian SSH] D[Fedora SSH] A-->B B-->C B-->D C<-->|SystemD Patches|D

Esses patches nunca entraram no Portable OpenSSH, porque o pessoal do Portable
OpenSSH ["não estava interessado em assumir uma dependência do
libsystemd"][djmdjm]. E nunca entraram no OpenSSH upstream, porque
o OpenBSD não tem qualquer necessidade de suportar SystemD.



### Preocupações sobre "Separação de Responsabilidades"
Isto parece suficientemente inofensivo, mas é um exemplo de um problema muito maior
no Open Source, particularmente no Linux: componentes críticos do
sistema operativo são desenvolvidos por pessoas que não se conhecem, e
não falam umas com as outras.