17 грудня 2021 року у своєму блозі Google Open Source Insights Team прояснили всю ситуацію довкола вразливості Apache Log4j. Вони пояснили, в чому полягає вразливість і який поточний прогрес у виправленні проблем екосистеми з відкритим кодом JVM. Також команда поділилася своїми думками про те, скільки часу може знадобитися, щоб цю вразливість було виправлено в усій екосистемі та на чому слід зосередитися далі.
9 грудня спільнота інформаційної безпеки дізналася про існування вразливості, яка має великий ступінь серйозності та потенційну широту впливу. Десятки тисяч програмних пакетів (артефактів, як вони називаються в екосистемі Java) і проектів використовують популярний інструмент журналювання, log4j, який, як виявилося, має в собі вразливість. Як пояснюють спеціалісти,вразливість дозволяє віддалено виконувати код, використовуючи функцію пошуку JNDI, відкриту бібліотекою журналювання log4j. У багатьох версіях бібліотеки експлуатована функція існувала за замовчуванням.
Виправлення вразливості Apache Log4j займе трохи часу
Не так давно розкриті вразливості log4j торкнулися понад 35 000 пакетів Java, що становить понад 8% репозиторію Maven Central. Оскільки репозиторій є найбільшим сховищем пакетів Java, це стало значною проблемою для багатьох фахівців індустрії програмного забезпечення. Фахівці зазначають, що 8% є величезним показником для екосистеми, в той час як середнє число для результату консультацій Maven Central складає 2%, з медіаною менше 0,1%. Хоча згадані числа не охоплюють всі пакети Java, наприклад безпосередньо розподілені бінарні файли.
На момент публікації було зафіксовано майже п’ять тисяч виправлених артефактів. І понад 30 000 артефактів, багато з яких залежать від іншого артефакту, і все ще чекають на виправлення. Команда завважує, що вони зараховували артефакт як виправлений, якщо він мав принаймні одну вражену версію, і було випущено більш стабільну виправлену версію (відповідно до семантичних версій). У випадку log4j артефакт вважається виправленим, якщо він був оновлений до версії 2.16.0 або вище і не залежить більше від log4j.
Дві серйозні проблеми заважають процесу виправлення
Хоча в цілому ситуація зрозуміла, фахівці вказують на дві істотні проблеми щодо її усунення. Перше це той факт, що багато артефактів опосередковано залежать від log4j. А ті, що мають пряму залежність, становлять близько 7000 вражених артефактів. В першому факті будь-яка з його версій залежить від ураженої версії log4j-core або log4j-api, описаних в CVE. Тобто це непряма залежність або транзитивна залежність, що означає, тавтологічно сказано, залежності власних залежностей.
Весь цей набір залежностей створює значні перешкоди у виправленні, якщо прослідкувати все це в ланцюжках залежностей. Тоді все стає зрозумілим: чим глибше вразливість, тим більше потрібно перебрати ланцюжків, щоб її усунути. Згідно з гістограмою графіків залежностей у більш ніж 80% пакетів вразливість залягає глибше ніж на один рівень. У більшості це п’ять рівнів нижче, а в деяких – навіть дев’ять. Процес виправлення в таких випадках вимагає спочатку перейти до найглибших залежностей, і далі поступово по всій кроні.
Відкритий діапазон дає можливість вибрати останню версію
Інша складність полягає у виборах на рівні екосистеми в алгоритмі розв’язання залежностей та умовах специфікації вимог. Практика відрізняється від такої, як в npm, де звичайно вказуються відкриті діапазони для вимог залежностей. Відкриті діапазони дають можливість вибрати останню випущену версію, яка задовольняє вимоги залежностей, тим самим виводячи в перший список оновленні версії. Користувачі отримують виправлену версію одразу після випуску виправлення, процес, який генерує залежності швидше.
«В екосистемі Java звичайною практикою є указання вимог до «м’яких» версій — точні версії, які використовуються алгоритмом розділення, якщо жодна інша версія того самого пакета не з’являється раніше на графіку залежностей. Виправлення часто вимагає додаткових дій з боку розробників, щоб оновити вимоги залежностей до виправленої версії», — також писала команда Open Source Insights щодо цього у своєму блозі.
В цьому питанні команда радить спільноті увімкнути автоматичне оновлення залежностей та додати засоби підсилення безпеки. Вони також надали список з 500 вражених пакетів з транзитивною залежністю. На думку фахівців, визначення пріоритетності цих пакетів полегшить зусилля з виправлення та згодом розблокує більшу частину спільноти. Команда подякувала користувачам, які оновили свої версії log4j.
На питання, скільки часу знадобиться, щоб повністю виправити все, команда висловилася неоднозначно. Якщо розглядати всі публічно доступні критичні рекомендації, що впливають на пакети Maven, то процес може зайняти деякий час. Вони кажуть, що менше половини (48%) артефактів, на які вплинула вразливість, було виправлено. Але що стосується log4j, то все здається багатообіцяючим: приблизно 13% було виправлено.
