Історія про трьох уязвимостях ядра

      Нещодавно Trustwave, фірма спеціалізується на інформаційній безпеці, опублікувала анонс звіту , в якому критикується, як Linux-спільнота справляється з уразливими. У ньому сказано: «Розробники програмного забезпечення сильно різняться в своїй здатності реагувати і усувати уразливості нульового дня. У цьому дослідженні показано, що у розробників Linux найгірший час реагування: з моменту виявлення уразливості до виходу патча в середньому проходить майже три роки ». Незалежно від того, наскільки ви задоволені оновленнями безпеки в Linux, три роки — це набагато більше, ніж ми зазвичай очікуємо. Ваш покірний слуга вирішив дослідити ситуацію, сконцентрувавшись на двох уязвимостях, які були включені до звіту Trustwave і на одній, якої там не було.
 
 Три роки?
На момент написання статті, повний звіт Trustwave ще не був доступний (зараз його можна завантажити тут . — Прим. Пров. ), тому детальне вивчення представлених тверджень не представляється можливим. Але, судячи з цієї статті на ZDNet , середній час відповіді було обчислено за цими двома вразливостям нульового дня:
 
 
     
  • CVE-2009-4307 : помилка ділення на нуль в коді файлової системи ext4. Для експлуатації цієї уразливості необхідно, щоб користувач змонтував спеціально підготовлений образ файлової системи ext4.
  •  
  • CVE-2009-4020 : переповнення буфера в файлової системі HFS +; експлуатується, знову ж таки, шляхом монтування спеціально підготовленого образу файлової системи на цільовій системі.
  •  
 
Про проблему, пов'язаної з файлової системою ext4, повідомив RN Sastry 1 жовтня 2009, який проводив fuzz-тестування файлової системи (тип тестування, при якому пошук помилок здійснюється за допомогою випадкових вхідних даних. — Прим. Пров. ). Повідомлення про помилку включало в себе і образ файлової системи, що провокує баг, що по суті є «експлойтів» для цієї уразливості, що дозволило Trustwave називати це вразливістю нульового дня. І, оскільки проблема викликала всього лише kernel oops (системна помилка, після якої часто трапляється kernel panic — Прим. Пров. ), а також вимагала співпраці з боку жертви (монтування файлової системи, підготовленої атакуючим), розробники ext4 не вважали за потрібне все кидати і відразу ж усувати уразливість. Ted Ts'o закоміттіл виправлення наприкінці листопада. SUSE перший опублікували оновлення з усуненням уразливості, це трапилося 17 січня 2010 року. Red Hat не випускала оновлення до кінця березня, майже п'ять місяців з моменту появи інформації про уразливість, а Mandriva чекала до лютого 2011.
 
Можна стверджувати, що все відбувалося нешвидко, навіть для бага з надзвичайно низьким пріоритетом, але звідки ж взялися ці «три роки»? Вони з'явилися через те, що виправлення не працювало належним чином на x86 архітектурі. Xi Wang повідомив , що проблема як і раніше існує, 26 грудня 2011 року і надіслав путнє виправлення 9 січня 2012. Цій проблемі був призначений новий номер CVE (CVE-2012-2100 ), і виправлення було оперативно влито в основну гілку. Мейнтейнери не були особливо моторні, проте Debian випустив оновлення в березні, Ubuntu — у травні, а Red Hat прочекав до середини листопада. Знадобилося приблизно одинадцять місяців після виявлення уразливості, щоб доставити виправлення до користувачів. З моменту виявлення проблеми до виходу оновлення Red Hat, яке остаточно вирішило проблему, дійсно, пройшло більше трьох років.
 
Історія з HFS / HFS + дуже схожа. Перший патч , вирішальний проблему з переповненням буфера в HFS, був опублікований Amerigo Wang на початку грудня 2009 року. Виправлення було закоммічено Линусом 15 грудня, а мейнтейнери Red Hat почали поширювати оновлення 19 січня 2010 року. Деякі мейнтейнери були ще більш повільними, але ця вразливість також була визнана трудноексплуатіруемой і вважалася фонової.
 
Проблема в тому, що ядро ​​підтримує іншу (більш свіжу) файлову систему під назвою HFS +. Це окрема реалізація, що містить неабияку кількість коду, скопійованого з оригінальної реалізації HFS так само, як ext4 була розпочата з копіювання ext3. Небезпека такого дублювання коду чудово відома: розробник виправляє проблему в одній копії, навіть не підозрюючи, що така ж проблема може бути і в іншій. Природно, що це сталося і тут. Реалізація HFS + мала таку ж уразливість переповнення буфера, але ніхто і не подумав про це, поки Timo Warns не притягнув увагу кількох розробників ядра в кінці квітня 2012 року. Greg Kroah-Hartman опублікував зміни 4 травня, і проблема набула розголосу через кілька днів після цього. І знову був призначений новий номер CVE (CVE-2012-2319 ), і знову мейнтейнери просачковалі з виправленнями. OpenSUSE випустило оновлення в червні, у той час як в Red Hat прочекали до жовтня, пройшло п'ять місяців з моменту того, як про проблему стало відомо. З моменту виявлення до публікації виправлення в Red Hat пройшло трохи менше трьох років.
 
Але на цю проблему можна дивитися під різними кутами. З одного боку очевидно, що Trustwave спеціально вибрали ці уразливості і потім інтерпретували їх так, щоб показати максимально можливий час виправлення. Але жодна з історій не описує вразливість нульового дня, яка залишалася б відкритою протягом трьох років; більшу частину часу передбачалося, що проблема вирішена. Це удвічі вірно для HFS +, про уразливість в якій навіть не було відомо до травня 2012 року. І, враховуючи характер цих вразливостей, дуже малоймовірно, що black hat'и ревно приховували їх весь цей час, і, швидше за все, жодна система не була скомпрометована з їх використанням. Претензії Trustwave, якщо вони засновані на цих двох уязвимостях, в кращому випадку є сумнівними і перебільшеними.
 
З іншого боку, навіть низькопріоритетні уразливості, що вимагають дій жертви, повинні бути виправлені, коректно і по-можливості швидко. Але, насправді, не все так просто з тим, що сталося з цими уразливими. Реакція на проблему з ext4 була досить швидкою, особливо враховуючи характер проблеми, але той факт, що на x86 архітектурі проблема все ще була актуальна, показує що як мінімум тестування було, щонайменше, незадовільним. У випадку з HFS / HFS +, хто взагалі може засуджувати кого-небудь за те, що він не подивився, чи немає дубліката бага в якомусь іншому місці? На тлі того, що файлові системи HFS і HFS + майже не використовуються і, можна сказати, не підтримуються, претензії не витримують критики. Однак атакуючі не обмежуються добре підтримуваним кодом І, для обох випадків, мейнтейнери взагалі не потурбувалися доставкою виправлень своїм користувачам. Можна б було працювати і трохи краще.
 
 Тим часом у 2013
Ймовірно, повільність показана вище — це природна відповідь на уразливості, які насправді нікого не хвилюють. Якби вони вони були більш серйозними реакція, безперечно, була б набагато краще. І як це зазвичай буває, під час написання статті (стаття опублікована 19 лютого 2013. — Прим. Пров. ), існує незакрита уязімость, так що ми зможемо поспостерігати за тим, наскільки добре ми можемо реігіровать. І відповідь не обнадійливий.
 
20 січня дискусія з приватного списку розсилки з безпеки ядра стала публічною в зв'язку з публікацією патча за авторством Олега Нестерова. Було продемонстровано, що реалізація системного виклику
ptrace()
в ядрі Linux містить стану гонки: регістри трассируемого процесу можуть бути змінені таким чином, щоб ядро ​​відновило вміст стека цього процесу в довільному місці. У кінцевому рахунку це призводить до можливості виконання довільного коду в режимі ядра. Атака здійснюється локально, тому зломщик повинен запустити експлоїт на цільовій системі. Але отримавши можливість запустити таку програму, він може користуватися повним набором привілеїв користувача root. Такого роду уразливості вимагають негайного уваги. Будь-яка система з подібною уразливістю фактично віддана на мілось будь-якого (в т. ч. недовірених) користувача, що має аккаунт, або будь-якого зломщика, який може скомпрометувати мережевий сервіс і запустити довільну програму.
 
15 лютого вразливість була виявлена ​​і опублікована, причому з дуже якісним кодом для експлойта, для тих хто не хоче писати свій. Більшість жертв навряд чи застосують патч до ядра, щоб було легше реалізувати стан гонки, також експлойт потрібно працювати в режимі реального часу, щоб надійніше виграти гонку. Але навіть без патча і роботи в реальному часі, досить терплячий атакуючий зможе отримати результат. Ось як відреагував на виявлену уразливість Solar Designer:
 
 
Я ще не встиг уважно подивитися на все це, але на перший погляд, це найгірша вразливість за кілька років. Для мейнтейнеров дистрибутивних ядер (відмінних від основної гілки, яку запатчілі майже місяць тому) це 0-day.
 
 
Взагалі-то, це не повинна бути уразливість нульового дня, оскільки публічному обговоренню виправлення вже близько місяця, а приватна тривала ще деякий час до цього. Але на момент написання, ще жоден дистрибутив не випустив оновлення для цієї проблеми. Що приводить нас до деяких очевидним питань. Знову цитуємо Solar Designer:
 
 
комітів Олега Нестерова з Red Hat в потрапили в основну гілку ще в січні. Чому в Red Hat проблема не була (?) Оброблена з усією серйозністю, ну або, зрештою, не було опубліковано інформацію, які з їхніх ядер схильні до цієї уразливості на даний момент.
 
 
Ця заява змушує припустити, що схожі проблеми можливі і в майбутньому. А поки користувачам і системним адміністраторам по всьому світу потрібно хвилюватися, уразливі чи їх системи, і те, хто може проексплуатувати ці уразливості.
 
І знову: ми можемо працювати краще. З самого початку було відомо, що це серйозна проблема; один з розробників, який повідомив про неї (Salman Qazi з Google) також доклав і експлойт, щоб показати, наскільки ситуація серйозна. Мейнтейнери знали про проблему і мали достатньо часу, щоб відреагувати на неї, але все одно не відреагували вчасно. Проблема з
ptrace()
зважилася менше ніж за 3 роки, але тут нема чим пишатися. Користувачів не можна залишати напризволяще на цілий місяць (якщо не більше), з того часу, як мейнтейнери дізналися про цю проблему.
 
Примітка від перекладача:
Виправлення в Debian було випущено 25 лютого, в Red Hat — 26 лютого, в Ubuntu — 21 лютого, в OpenSUSE — 25 лютого.
  
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.