У пакеті XZ Utils виявили бекдор

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Проблему помітив розробник Андрес Фройнд. Він працював над продуктивністю системи Debian із SSH та помітив, що проблеми виникають після оновлень XZ Utils (ран. LZMA Utils). Адже хтось навмисне встановив туди бекдор.

Як зазначили у блозі Red Hat, це втручання потенційно може дозволити зловмиснику зламати автентифікацію SSHD і отримати неавторизований доступ до всієї системи віддалено.

Юзерів відразу закликали припинити користуватися версіями 5.6.0 і 5.6.1 пакета xz.

На вашу думку, наскільки критичною є така вразливість? Чи вплине це на вашу роботу?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Поки що «так собі». Це може бути українець, білорус, фінн, ізраїльтянин, палестинець, грек... і припусковні цілі і ідеологія у них дуже різна.
Може, українець хотів зробити засіб для атаки проросійських серверів. А може, прихильник Олександра Македонського хотів відродити Велику Грецію від Неаполя до Карачі. Як зʼясувати правду?

Варто коменти почитати під цим постом, плюс аргумент про робочи часи теж так собі, всіх сильно різні люди бувають. Я скоріш повірю, виходячи зі складності бекдору, що працювали з якоїсь віртуальної або підставної машини(середовища), щоб точно нічого про себе не спалити.

Федорине горе читав і дфафільм диіився
Кацапський білд лінуксу

1. Fedora 40 і 41 ще не випущені в реліз.
2. 5.6.0 і 5.6.1 — це версії пакету xz, а не Fedora.

Із всіх відомих дистрибутивів лінукса, версія xz із бекдором потрапилла тільки в реліз Arch Linux. Дістр для фріків.

Висновнок:
— автору посту — незалік. Виправьте фактичні помилки в пості.
— цей бекдор не наніс ніякої реальної шкоди. Якби він портапив в стейбл реліз якогось відомого дістрибутиву, який використоовується для серверів — це була б катастрофа. Її вдалось попередити.

Із всіх відомих дистрибутивів лінукса, версія xz із бекдором потрапилла тільки в реліз Arch Linux. Дістр для фріків.

От тільки в Арчі openssh не лінкується з liblzma, та й сам бекдор не тріггериться під час білду на не-Дебі і не-RPM.

Він ніде безпосередньо з liblzma не лінкуєцця, тільки подекуди через libsystemd. Та й тут уже ні, бо втягнуто зміни для підвантажування бібліотек компресії через dlopen(). Вони потрібні тільки для journald/journalctl. Хоча, гадаю, саме ця зміна в Fedora 40 ше не зайде.

Взагалі, лінкувати цілий libsystemd тіко для sd_notify() — теж так собі ідея, це як купити пасажирський літак, бо тобі з нього лампочка для читання потрібна. Там прості текстові повідомлення через сокет, можна склепати самому.

Fedora 40 стає базою для RHEL 10, це суперціль для такого експлойту. І ще убунту 24.04 LTS

Дякую, ми виправили неточності щодо версії пакета xz.

heartbleed как-то пережили, так openssl в половине серверов установлена) а дыра была известна узкому кругу лиц.
Проблема liblzma что разрешили комитить блобы и дали маинтейнера какому-то анониму, который с нескольких аккаунтов пушил автора

дали маинтейнера какому-то анониму,

95% OSS маінтейнять «якісь аноніми»
Це більше схоже на проблему глобального «dll hell», ніж на проблему суто liblzma

Дістр для фріків 😂 Steam Deck runs SteamOS version 3, based on the Arch Linux operating system. 🤣 це так з грубого ...

Хм. Неочікувано, дякую :)

Хех, насправді ролінг-оут дістри круто брати для такого пристрою, якщо ви збираєтесь підтримувати його чуть більше ніж всякі «китайські замінники телефонів ідентичних натуральним» — зробив собі зеркало і по тихому постійно тримаєш пристрій в тонусі, без «пожеж» по типу «новий реліз» ...

сообщество os в очередной раз показало высокую эффективность контроля, когда смотрят множество глаз. в коммерческом продукте все это весело бы уехало в релизы и никто бы не почесался

Спільнота OS показала, що абсолютно випадкова особа, про яку нічого не відомо, окрім емейлу, використовуючи кілька фейкових акаунтів, за рік отримала статус мейнтейнера і можливість пушити випадкові зібрані власноруч релізи прямо в репозиторії Debian...

А чим це відрізняється від абсолютно випадкової особи, яка прийшла на роботу в Microsoft, і може пушити коміти прямо в репозиторій Windows?

Цю випадкову особу перевірить служба безпеки, перш ніж дати доступ до репозиторію. Та не дозволять пушити релізи клієнтам після п’яти комітів у допоміжні скрипти.

Та будь-яку ідеальну особу можуть підкупити, залякати, шантажувати або хакнути її комп. Опенсорс тут як раз максимально захищений, бо він розподілений на відміну від однієї закритої компанії. Єдине що потрібне — рев’ю кода.

а після походу з тімлідом по бабам — дадуть доступ.
це ж корпорації. там оно студент в цру доступ до секретних документів мав, а тут щоб у дева не було можливості добитися потрапляння чогось в прод?

І що? Ну ось мене перевірили, я такий собі пересічний Василь Петренко, мідл C++. Завтра до мене підходить чоловʼяга з пропозицією, від якої не можна відмовитись, а взамін обіцяє, по завершенню операції, нові документи, іншу країну і, якщо хочу, пластичну операцію. А внутрішнього ревʼю нема і я комічу усяку повну хєрню, на яку навіть начальник дивиться по принципу «ну тут є відомі слова, все значить ок» і може задати пару питань типа «чому ти в регістр 0xcc0022 поклав 3, а не 2». Ревізії старого коду нема від слова «зовсім». І вистрілить моя закладка років через 3-4. К тому моменту я буду в іншій країні... або під землею, бо виконувати обіцянки той тип не стане.

Про якість контроля я серйозно — на кількох проектах саме класу «linux embedded» все що було це гонка за фічами, і добре коли хоча б регресії перевірялись (на деяких і того не було! я міг зламати сусіду що завгодно і помітили б це тільки через півроку у кращому випадку). Був sonarqube, який перевіряє зовсім інше. І все.

А юзерів у одного з проектів було декілька мільйонів. Ось і рахуйте, скільки таких закладок _реально_ є у тих системах, що ми використовуємо кожного дня...

не рік, а два. похибка всього в два рази)
> 2021-10-29: Jia Tan sends first, innocuous patch to the xz-devel mailing list, adding “.editorconfig” file.
> 2024-02-23: Jia Tan merges hidden backdoor binary code well hidden inside some binary test input files.

> 2024-02-24: Jia Tan tags and builds v5.6.0 and publishes an xz-5.6.0.tar.gz distribution with an extra, malicious build-to-host.m4 that adds the backdoor when building a deb/rpm package. This m4 file is not present in the source repository, but many other legitimate ones are added during package as well, so it’s not suspicious by itself. But the script has been modified from the usual copy to add the backdoor. See my xz attack shell script walkthrough post for more.

Тобто файли, які використовуються при білді релізів, у репо не трекаються...

Тобто порушуються мінімальні правила для supply chain consistency...

Правда. Терміново всім на шиндошс.

Анонімне журнашлю, застрілися само. Ти переплутало все що могло.

По сути: 1) Не вплине. 2) Пʼятирічну підготовку спалив один хакер, який просто помітив затримку. Може, він аутист, але йому велика дяка.

Х його З...

5.6.0 та 5.6.1 це не версії Федори, а версії libxz. Жодна non-testing дистрибуція їх ще не встигла включити, окрім always-on-the-edge дистрибуцій, таких як Kali (хаха), Gentoo та подібних. Тобто, реальний вплив близький до нуля...

Але ситуація, як така, дуже добре ілюструє поточний стан security у більшості опенсорсу...

Більшість не-опенсорсу від подібного віддаляє всього 1-2 рев’ювери при мр і на кілька порядків менші шанси на дизасемблювання і аналіз сторонніми розробниками.

Це не про рев’ю, це про імпорт рандомних релізів рандомного софта, зробленого рандомними людьми, з заплющеними очіма...

А де брати не-рандомний?

Хоча б pin’ити версії там перевіряти чексуми...

Від того що залежності вендоряться і кладуться у всіляких артіфакторях, менш «зробленими рандомними людьми» вони не стають, а повільні процедури апдейтів захищають від 0-day, зате сповільнюють доставку фіксів для старих вразливостей.
Навряд чи ця задача має правильне рішення, з цієї історії вибивається з загального ряду хіба що недосконалість підходу autotools для харденінгу.

для кого це важливо — пінить версії, сидить на стеблі дебіану з п’ятирічної давнини протестованими пакетами.
А тут бекдор закомітила людина, котрій вдалося в офіційні мейнтейнери пакету пробратися.
тож тут геть не про безумний імпорт рандомного софту. це, все ж, не nodejs екосистема..

А також бекграунд чек на етапі доступа в репо, з перевіркою документів. Тут основна проблема, що мейнтейнер, що включив бекдор — то persona, а не реальна людина. Нема кого притягнути до відповідальності, імейл до справи не пришьєш.

В Штатах точно можна пошити справу на невідому особу, яка представлялась як Х, користувалась імейл-адресою У, зробила заборонений чин Й. Коли їх знайдуть, то вже пофіг, скіко їх там насправді було.

Дякую, ми виправили неточності щодо версій.

Підписатись на коментарі