Нещодавно новина про це заявила Виявлено критичну вразливість у сховище пакетів rubygems.org (уразливість уже внесена в каталог CVE-2022-29176), що дозволяє без належного дозволу, замінити чужі пакунки у сховищі, витягнувши легітимний пакет і завантаживши на його місце інший файл з тим же ім’ям і номером версії.
Згадується, що вразливість пов'язана з помилкою в обробнику дій "yank"., який розглядає частину імені після дефісу як назву платформи, що дозволило ініціювати видалення зовнішніх пакетів, які відповідають частині імені до символу дефісу.
Зокрема в коді контролера операції «дергання», дзвінок 'find_by!(повне_ім'я: "#{rubygem.name}-#{slug}")' використовувався для пошуку пакетів, тоді як параметр "slug" був переданий власнику пакета для визначення версії для видалення.
Власник пакета "rails-html" міг вказати "sanitizer-1.2.3" замість версії "1.2.3", що призведе до застосування операції до "rails-html-sanitizer-1.2.3" пакет ″ від когось іншого. »
Вчора було опубліковано рекомендацію щодо безпеки для Rubygems.org.
Повідомлення стосувалося помилки, яка дозволяла зловмисникові видобувати певні дорогоцінні камені та завантажувати різні файли з однаковою назвою, номером версії та іншою платформою.
Давайте глибше подивимося, що пішло не так під час процесу вилучення. Як привід, уявімо сценарій, де ми створюємо дорогоцінний камінь під назвою "rails-html" з наміром отримати несанкціонований доступ до широко використовуваного дорогоцінного каменю "rails-html-sanitizer".
Згадується, що повинні бути виконані три умови, щоб успішно використати цю уразливість:
- Атаку можна здійснити лише на пакети, у назві яких є символ дефіс.
- Зловмисник повинен мати можливість розмістити набір дорогоцінних каменів із частиною імені до символу дефіса. Наприклад, якщо атака спрямована на пакет "rails-html-sanitizer", зловмисник повинен помістити свій власний пакет "rails-html" у сховище.
- Атакований пакет повинен бути створений протягом останніх 30 днів або не оновлювався протягом 100 днів.
Проблема був ідентифікований дослідником безпеки як частина програми винагород HackerOne для пошуку проблем безпеки у відомих проектах із відкритим кодом.
Проблема виправлено на RubyGems.org 5 травня і за словами розробників, ще не виявили слідів експлуатації вразливості в журналах за останні 18 місяців. При цьому наразі проведено лише поверхневий аудит, а надалі планується більш глибокий.
Наразі ми вважаємо, що ця вразливість не була використана.
RubyGems.org надсилає електронний лист усім власникам дорогоцінних каменів, коли версія дорогоцінного каміння виходить або видаляється. Ми не отримували жодних листів підтримки від власників дорогоцінних каменів про те, що їхній дорогоцінний камінь було видобуто без дозволу.
Аудит змін дорогоцінних каменів за останні 18 місяців не виявив прикладів зловмисного використання цієї вразливості. Подальший аудит щодо будь-якого можливого використання цього експлойту не виявив жодного прикладу використання цього експлойту для захоплення дорогоцінного каменю без дозволу в історії RubyGems. Ми не можемо гарантувати, що цього ніколи не було, але це малоймовірно.
Для перевірки ваших проектів рекомендується проаналізувати історію операцій у файлі Gemfile.lock Шкідлива активність виражається в наявності змін з однаковою назвою та версією або зміні платформи (наприклад, коли пакет xxx-1.2.3 .1.2.3 оновлено до xxx-XNUMX-xxx).
Як рішення проти спуфінгу прихованих пакетів у системах безперервної інтеграції або під час публікації проектів, Розробникам рекомендується використовувати Bundler з параметрами «–заморожено» або «–розгортання» щоб підтвердити залежності.
Нарешті, якщо вам цікаво дізнатись більше про це, ви можете перевірити деталі в наступне посилання.