в ответ на Hacker News...

Вижу, вы, шутники с [оранжевого сайта][hn], решили меня подколоть. Ниже я дам несколько избранных ответов, но сначала предлагаю вызов: я отправлю 500 долларов из своих денег первому, кто сможет продемонстрировать эту атаку без ifunc. Мне искренне интересно, и я готов заплатить за просвещение. Форкните этот репозиторий и отправьте PR с работающим PoC, я приватно запрошу ваш почтовый адрес, если вы победите. А теперь ответы:

Это лает не на то дерево.

Дитя, я живу не на том дереве, я могу лаять на кого захочу.

Это не было существенно для эксплойта,

Ты не существенен для эксплойта!

Всегда есть selinux, если мы хотим добавить защиту от выполнения произвольного кода от имени root.

После загрузки эта атака не нуждалась в пересечении каких-либо дальнейших границ системных вызовов. Так что да, мы могли бы ограничить «бонусную» root-сессию, но у нас всё равно были бы незваные гости на машине!

Что это, день рождения Бильбо?? Вход только по партийным делам!!

1. IFUNC — далеко не единственный способ выполнить код до main.

Но это ненужный способ выполнить код до того, как настроена защита памяти

2. Альтернатива, которую они предлагают, возможно, менее безопасна, потому что указатель на функцию останется записываемым на протяжении всего времени жизни процесса,

Мы можем схитрить с mprotect! См. последнее предложение перед подразделом Modifying LD_PRELOAD.

Да, этот блог заблуждается.

Прошу прощения, этот блог был неуправляемым. Я сам устроил все эти шалости! Никто не заставлял меня быть настолько глупым.

IFUNC должен быть реализован самим [клиентским] программным обеспечением,

@CountWSS 💯 чёрт возьми, да

серия вопиющих процессных провалов со стороны мейнтейнера Github вплоть до ...

Это единственный пункт, на который я отвечу всерьёз:

Я считаю крайне несправедливым по отношению к мейнтейнеру xz-utils и довольно опасным для сообщества рассматривать это как начавшееся с его ошибки. Это началось с того, что никому не было дела до помощи в поддержке этого проекта. Атакующий полагался на ifunc как на техническую уязвимость, а на нашу коллективную халатность в отношении xz-utils — как на социальную уязвимость. Я считаю постыдным видеть в действиях мистера Коллина что-либо иное, кроме героической, многолетней преданности служению сообществу.

Кроме того, Брюс Шнайер согласен со мной так что... смиритесь, ваш аргумент разбит.

Язык мог быть резче, чем нужно

Вы не поверите, насколько мои друзья заставили меня сначала всё это смягчить.

Дистрибутивы Linux не должны быть настолько высокого мнения о себе, чтобы ожидать, что OpenBSD будет соответствовать и адаптироваться к их бардаку

@debazel!!! Me gusta.

Что за полная чушь.

Ладно, вот эта часть точна.

IFUNC'd up

Почему вам стоит перестать винить xz-utils в [CVE-2024-3094][nvd]. Также посмотрите мой доклад на ETSA!

CVE-2024-3094, более известная как «бэкдор в xz-utils», была почти промахом для глобальной кибербезопасности. Если бы эта атака не была обнаружена в самый последний момент [Андресом Фройндом][freund], большинство SSH-серверов на нашей планете начали бы предоставлять root-доступ стороне, стоящей за этой атакой.

К сожалению, слишком много анализа сосредоточено на том, как [вредоносный код][JiaT75] попал в репозиторий xz-utils. Вместо этого я хотел бы утверждать, что именно два давних проектных решения в критически важном открытом программном обеспечении сделали эту атаку возможной: [линковка OpenSSH с SystemD][biebl] и существование [GNU IFUNC][sourceware].

Прежде чем начать: Большая часть этого обсуждения касается тонкостей динамической линковки в Linux. Если вам нужно освежить знания, посмотрите dynamic_linking.md.

Краткий обзор CVE-2024-3094

Существует масса хороших разборов, описывающих высокоуровневые детали бэкдора в xz-utils, например [What we know about the xz Utils backdoor that almost infected the world][goodin1] Дэна Гудина и gist Сэма Джеймса [FAQ on the xz-utils backdoor (CVE-2024-3094)][thesamesam]. Нам не нужно пересказывать всё это здесь, так что для целей этой статьи вот очень грубый обзор:

• Некоторые дистрибутивы Linux модифицируют OpenSSH, чтобы он зависел от SystemD
• SystemD зависит от xz-utils, который использует GNU IFUNC
• Следовательно, xz-utils оказывается в адресном пространстве OpenSSH
• Это позволяет ifunc модифицировать код в 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

## Почему дистрибутивы Linux модифицируют OpenSSH?
Короткий ответ: они вынуждены это делать. OpenSSH разрабатывается
сообществом OpenBSD, для сообщества OpenBSD, и им совершенно
безразличен Linux. Проект [Portable OpenSSH][mindrot] — это
сборник патчей, созданных по мере возможности, которые заменяют
специфичные для OpenBSD компоненты на универсальные компоненты POSIX,
а также некоторый платформозависимый код, где это применимо. Цепочка
поставок программного обеспечения для SSH на практике выглядит
примерно так:```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

Версия OpenSSH от OpenBSD является вышестоящей по отношению ко всему остальному, и большинство улучшений в неё приходит из сообщества OpenBSD. Эти изменения распространяются вниз по цепочке в проект Portable OpenSSH, который пытается реализовать новые функции способами, не специфичными для OpenBSD. Именно это позволяет SSH работать на таких платформах, как Linux, macOS, FreeBSD и даже Windows.

Но на этом дело не заканчивается. Некоторые операционные системы применяют дополнительную кастомизацию сверх того, что предоставляет Portable OpenSSH. Например, Apple добавляет флаг [--apple-use-keychain][keith] к ssh-add, чтобы помочь ему интегрироваться с менеджером паролей macOS.

В случае CVE-2024-3094 Fedora и Debian поддерживали собственные [патчи SystemD][biebl] для своих форков OpenSSH, чтобы исправить [состояние гонки при перезапуске sshd][schmidt]. Так что фактическая цепочка поставок для SSH стала выглядеть так:```mermaid flowchart TD A[OpenSSH] B[Portable OpenSSH] C[Debian SSH] D[Fedora SSH] A-->B B-->C B-->D C<-->|SystemD Patches|D

Эти патчи так и не попали в Portable OpenSSH, потому что люди из
Portable OpenSSH были ["не заинтересованы в получении зависимости от
libsystemd"][djmdjm]. И они так и не попали в upstream OpenSSH, потому что
в OpenBSD нет никакой необходимости поддерживать SystemD.



### Опасения по поводу "разделения ответственности"
Это кажется достаточно безобидным, но это пример гораздо более крупной проблемы
в Open Source, особенно в Linux: критически важные компоненты
операционной системы разрабатываются людьми, которые не знают друг друга и
не общаются друг с другом.