GnuTLS виправляє помилку неправильного керування пам’яттю – оновіть зараз!

Майже напевно найвідоміша криптографічна бібліотека у світі відкритого коду OpenSSL.

По-перше, це один із найпоширеніших, аж до того, що більшість розробників на більшості платформ чули про нього, навіть якщо вони не використовували його безпосередньо.

По-друге, це, мабуть, найбільш широко розрекламований, на жаль, через досить неприємну помилку, відому як Heartbleed який був відкритий більше восьми років тому.

Незважаючи на швидке виправлення (і незважаючи на наявність надійних обхідних шляхів для розробників, які не могли або не хотіли швидко оновлювати свої вразливі версії OpenSSL), Heartbleed залишається свого роду «вітриною» помилки, не в останню чергу тому, що це була одна з перших помилок, які його першовідкривачі перетворили на засіб агресивного піару.

З вражаючою назвою, власним логотипом і спеціальним веб-сайтом Heartbleed швидко став глобальною системою кібербезпеки суперісторія, і, добре чи погано, стало нерозривно пов’язане зі згадуванням імені OpenSSL, ніби небезпека помилки існувала навіть після того, як її було видалено з коду.

Життя за межами OpenSSL

Але є кілька інших криптографічних бібліотек з відкритим вихідним кодом, які широко використовуються, а також замість OpenSSL, зокрема, зокрема Mozilla NSS (скорочено для Послуги мережевої безпеки) і проекту GNU gnuTLS бібліотека

Як це сталося, GnuTLS щойно виправив помилку, відому як CVE-2022-2509, повідомляють у проекті консультування з питань безпеки GNUTLS-SA-2022-07-07.

Цей патч виправляє помилку неправильного керування пам’яттю, відому як a подвійний вільний.

Подвійне безкоштовне пояснення

Простіше кажучи, подвійна вразливість створюється, коли програміст просить операційну систему виділити блок пам’яті для тимчасового використання…

…і повертає його, щоб його можна було видалити зі списку позичених блоків, які будуть звільнені для використання іншими частинами програми…

…а потім випадково просить систему знову звільнити той самий блок пам’яті.

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

Делікатне поводження з подвійним звільненням, яке виявляється завчасно, є складною проблемою. Функція C, яка повертає пам'ять, створена як прототип void free(void *ptr); так що ви передаєте адресу блоку, який хочете звільнити, але не отримаєте назад код повернення. (функція змінного струму з a void Повернене значення - це те, що інші мови програмування називають a procedure: він робить щось для вас, але не має можливості повідомити про результат.) Таким чином, навіть ретельно написаний код C не має стандартного способу виявити, що щось пішло не так у free(), і, отже, неможливо впоратися з помилкою, спробувавши акуратно вимкнутись. Припинення програми-порушника в односторонньому порядку є єдиним безпечним рішенням для системи.

Але якщо розподільник пам’яті не усвідомлює (можливо, через те, що той самий блок згодом було передано іншій частині тієї самої програми, тому він повернувся до списку «позичених» у тому самому вигляді, що й був раніше) , то, швидше за все, трапяться погані речі.

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

Отже, у вас може вийти дві частини однієї програми, які маніпулюють одним і тим же шматком пам’яті.

Одна частина програми припускає, що вона може неявно довіряти вмісту пам’яті, оскільки вважає себе законним «власником» блоку.

У той же час інша частина програми знає, що вона може зіткнутися з даними (або може бути введена в дію), щоб навмисно збити першу частину.

Роблячи неправильні речі, ви робите правильні речі

За іронією долі, помилка CVE-2022-2509 існує в коді перевірки сертифіката в GnuTLS.

(Якщо вам цікаво, іронія полягає в тому, що програмне забезпечення, яке загалом є небезпечним, оскільки не перевіряє наявність надійних з’єднань TLS, захищено від цієї конкретної помилки безпеки.)

Наприклад, коли ви відвідуєте веб-сайт (або інший тип сервера), який захищено TLS, інша сторона зазвичай надсилає вам веб-сертифікат, який підтверджує, що сервер справді належить і керується організацією, яку ви очікуєте.

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

На практиці сертифікати зазвичай підписуються сертифікатом, який, у свою чергу, підписується сертифікатом, якому ваш браузер довіряє, але кінцевим результатом є те, що називається ланцюжок довіри який можна безпечно відстежити до сертифіката, який уже встановлено в списку так званих Довірені органи, також відомий як Roots , яким керує ваш браузер або операційна система.

Щоб спростити та прискорити процес перевірки ланцюжка сертифікатів, багато серверів не просто надсилають власний сертифікат і залишають браузеру «переслідувати ланцюжок» до надійного кореня.

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

У такому випадку GnuTLS правильно й безпечно перевірить наданий сертифікат, перш ніж звільнити блок пам’яті, що використовувався для його зберігання.

Але якщо інший кінець не надає попередньо згенерований ланцюжок сертифікатів, таким чином залишаючи GnuTLS створювати та перевіряти ланцюжок самостійно, тоді код GnuTLS випадково звільняє пам’ять, яка використовується для зберігання наданого сертифіката, перш ніж він запустить ланцюжок- процес перевірки…

…а потім знову звільняє його після завершення перевірки.

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

Перегляд збою для імплантації шкідливого програмного забезпечення

Зазвичай, або принаймні часто, збої спричиняють таку неоднозначну поведінку, що операційна система виявляє, що програма-порушник втратила контроль над виконанням програми – наприклад, якщо програма перескакує на випадкову адресу пам’яті та намагається запустити код із блок пам'яті, який взагалі не був виділений.

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

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

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

Що ж робити?

Оновлення до Остання версія GnuTLS, який є 3.7.7 на момент написання.

(Ця помилка, очевидно, була представлена ​​в GnuTLS 3.6.0 і існує в кожній версії з того часу, аж до 3.7.6 включно.)

Зауважте, що багато популярних програм і інструментів для програмування включають або можуть бути створені для використання GnuTLS, навіть якщо ви можете не знати про це, включаючи, але не обмежуючись: FFmpeg, GnuPG, Mplayer, QEMU, Rdesktop, Samba, Wget, Wireshark і Zlib.

Багато пакетів Linux або *BSD, які використовують GnuTLS, покладатимуться на центральну версію, якою керує сам ваш дистрибутив, тому обов’язково оновіть його, щойно у вашому дистрибутиві з’явиться ця версія.

Щасливого виправлення!

---