11 жовтня 2023 року було помічено та усунуто вразливість високого рівня, що стосувалася переповнення буфера, в популярному інструменті та бібліотеці curl. Хоча виявилося, що ризику експлуатації вона не несе, недолік сприйняли надзвичайно серйозно через значний потенційний вплив. Ця публікація містить передісторію, технічну інформацію про цю вразливість, вказівки для усунення та розмірковування щодо майбутніх перспектив.
Загальна інформація про подію
- 11 жовтня 2023 року цю вразливість виявили, та виправлення було включено у реліз 8.4.0.
- CVE-2023-38545 впливає на всі версії curl, починаючи з 7.69.0, але вимагає дуже специфічних умов для експлуатації. Жодної атаки поки не виявлено.
- ПЗ, що пов’язані з інструментом curl або містять бібліотеку libcurl, рекомендовано виправити або оновити як мінімум до версії 8.4.0. Уникнення використання проксі SOCKS5 із curl також усуває проблему.
- Мільярди вразливих версій curl по всьому світу, ймовірно, залишатимуться в мережі роками, створюючи довгостроковий ризик, якщо їх колись зможуть експлуатувати.
Коли Даніель Стенберг, мейнтейнер інструменту та бібліотеки curl, оголосив, що виявлено серйозну вразливість, і відмовився надавати додаткові подробиці, доки не буде готове виправлення, світ кібербезпеки затамував подих. У тій чи іншій формі, open-source curl використовується в мільярдах інсталяцій програмного забезпечення, і недолік, який можна віддалено експлуатувати, міг би затьмарити кризу Log4j з точки зору наслідків.
На щастя, цього не сталося. Виявилося, що недолік був вразливістю переповнення буфера, яка впливала тільки на обмежену частину функціонала curl і лише за дуже конкретних обставин. На цей момент жодних практичних способів її експлуатації не було знайдено або помічено. Цю вразливість було усунуто в curl 8.4.0, і всі інсталяції curl мають бути виправлені або оновлені принаймні до цієї версії.
Можна подумати, до чого така метушня? Хоч ми й не будемо мати справу з іншим Log4Shell (або з неминучим псевдонімом Curl4Shell), але наслідки можуть проявити себе через багато років. Вразливість також поєднує в собі декілька поширених проблем із безпекою та була дуже детально описана розробником, що помітив і виправив її, тому вона варта більш глибокого аналізу.
Що таке curl, і де він використовується?
Curl (іноді пишеться як cURL) є основним інструментом командного рядка та бібліотекою для зв’язку програми з URL-адресами та отримання відповідей. По суті, якщо використовується скрипт або програма C/C++, якій потрібні дані з вебсторінки чи API, дуже ймовірно, що curl певним чином залучений у процес.
Більшість операційних систем постачаються разом із цим інструментом, а пов’язана бібліотека libcurl викликається або включається практично в будь-яку програму C/C++, що комунікує через HTTP. Важливо, що це також стосується вбудованих систем у пристроях, під’єднаних до Інтернету. Тому, за оцінками Даніеля Стенберга, може існувати близько 20 мільярдів встановлень curl. Порівняно з цим, заголовки “Log4j є всюди” безперечно здаються перебільшеними.
Вразливість переповнення буфера динамічної пам’яті в curl
Даніель Стенберг детально описав історію та технічні деталі вразливості у своєму блозі, але ось коротка спрощена версія:
- Curl має багато режимів роботи, включаючи один для комунікації через проксі SOCKS5, який можна застосовувати для тунелювання трафіку з внутрішньої мережі (подібно до VPN) і для обходу фільтрів трафіку. Вразливість впливає лише на curl, якщо використовується в режимі SOCKS5.
- Під час редагування старого коду для покращення якості з’єднань SOCKS5 була допущена помилка під час обробки надто довгих імен хостів (понад 255 байтів). Замість того, щоб відхилити їх, що було б очікуваним (DNS дає обмеження у 255 байтів, тому все, що важить більше, вірогідно, не дозволено), curl перемикається з віддаленого режиму на локальний і знову намагається відозмінити ім’я хоста.
- Якщо з’єднання SOCKS5 недостатньо швидке, curl чекає на додаткові дані та продовжує роботу. Через баг він не фіксує, що має працювати в локальному режимі, та знову намагається віддалено видозмінити занадто довге ім’я хоста, але цього разу він його все ж передає.
- Код видозмінює та відправляє ім’я хоста, не перевіряючи, скільки воно займає місця. Якщо розмір буфера становить від 16 КБ до 64 КБ, і вказано надзвичайно довге ім’я хоста, може статися переповнення буфера, яке перепише суміжну пам’ять. Командний рядок curl за замовчуванням налаштований на 100 КБ і є вразливим лише при зміні цього розміру, але програми, що використовують бібліотеку libcurl, мають 16 КБ за дефолтне значення, що робить їх вразливими.
- Атака може бути успішною, лише якщо операційна система не захищає від пошкодження пам’яті. Зловмисник також має додаткові складнощі через обмежений набір символів, дозволений в імені хоста.
Цей допис перелічує навіть не всі умови, необхідні для прояву вразливості. Знову ж таки, згадуючи Log4Shell, де один рядок тексту, надісланий на сервер в Інтернеті, зміг викликати виконання коду, здається, що недолік curl неймовірно складно експлуатувати. Однак, все дуже швидко змінюється. Зловмисні хакери знаходять все нові й нові способи для здійснення атак, тому важливо все виправити якомога раніше.
Розкриття вразливості, усування ризиків та звична паніка щодо безпеки
Попри низький ризик і відсутність продемонстрованого способу експлуатації вразливості, Даніель Стенберг дуже серйозно поставився до звіту та не розкривав жодних подробиць про баг (навіть яких версій це торкнулося), доки не з’явилося виправлення. Перед публікацією його надали мейнтейнерам ОС, щоб вони могли оновити curl у своїх системах. Ця додаткова затримка подовжила час спекуляцій щодо потенційно руйнівного впливу вразливості.
Патч і повні відомості про вразливість були опубліковані 11 жовтня 2023 року, і всі зітхнули з полегшенням: страхи не справдилися. Оновлення розв’язало проблему та, починаючи з версії 8.4.0, curl відхиляє занадто довгі імена хостів і відправляє повідомлення про помилку. Це усуває вразливість переповнення та робить безпечним використання curl у режимі SOCKS5.
Але це лише початок, адже, як і з усіма виправленнями для популярного програмного забезпечення, складно оновити все. Не всі користувачі curl мають змогу зробити це одразу. І багато хто може навіть не знати, що їхня система чи програма використовує curl. Інструмент і бібліотека постачаються з більшістю операційних систем або включені в них, що охоплює вбудовані системи (наприклад, пристрої ІоТ і мережеві пристрої), а також ПЗ, яке працює у віртуальних машинах і контейнерах.
Рекомендовані заходи для усунення ризиків у порядку переваги (з офіційних порад):
- Оновити curl до версії 8.4.0.
- Застосувати патч в локальній версії.
- Не використовувати проксі CURLPROXY_SOCKS5_HOSTNAME з curl.
- Не встановлювати socks5h:// змінну середовища проксі.
Ще одна ланка в крихкому ланцюжку постачання програмного забезпечення
Як і у випадку з кожною резонансною вразливістю управління пам’яттю, першою реакцією були заклики позбутися всього софта C/C++ та переписати його модною безпечною для пам’яті мовою, щоб нарешті не бачити переповнення буфера на перших місцях у топ 25 CWE. Це було б чудово в теорії, але абсолютно нездійсненно на практиці. Особливо для такого інструменту як curl, який широко використовують і вбудовують протягом більше двох десятиліть.
Весь цей страх можна списати на зайву обережність з боку мейнтейнера. Багато інших розробників програмного забезпечення, як для проєктів з відкритим вихідним кодом, так і для комерційних, ймовірно, підійшли б до цієї проблеми як до звичайного низькопріоритетного виправлення бага і додали б це кудись у примітки до релізу для наступної запланованої версії. Але для Даніеля Стенберга безпека є надважливою. Він відчуває тягар відповідальності як один із тих, хто підтримує основи всієї сучасної цифрової інфраструктури.
Навіть після релізу патча мільйони вразливих інсталяцій curl, ймовірно, існуватимуть багато років. Якщо ефективну атаку коли-небудь буде виявлено та використано, це може мати жахливі наслідки. Враховуючи крихкість глобального ланцюжка постачання програмного забезпечення, варто завжди пам’ятати про важливість кібербезпеки.
