GH Actions - Cache Poisoning
For further details check the original post https://scribesecurity.com/blog/github-cache-poisoning/
Cache Poisoning
Git action action/cache вводить механізм кешування в процесі безперервної інтеграції (CI), що охоплює два критичних етапи:
Run Action: Цей етап передбачає пошук і отримання кешованих даних під час виконання CI. Пошук використовує унікальний ключ кешу, що дає два результати:
Cache-hit: Запитувані дані знайдені в кеші і, відповідно, отримані для негайного використання.
Cache-miss: В кеші не знайдено відповідних даних, що спонукає до нового завантаження необхідних файлів і каталогів, подібно до запиту вперше.
Post Workflow Action: Цей етап присвячений кешуванню даних після виконання CI. Зокрема, якщо під час виконання дії виникає cache-miss, поточний стан вказаних каталогів кешується за допомогою наданого ключа. Цей процес автоматизований і не потребує явного виклику.
Security Measures: Cache Isolation and Access Restrictions
Для підтримки безпеки та забезпечення ізоляції кешу вводяться обмеження доступу, що створює логічне розділення між різними гілками. Наприклад, кеш, створений для гілки Feature-A (з основою в основній гілці), буде недоступний для запиту на злиття для гілки Feature-B (також базується в основній гілці).
Дія кешу дотримується певного порядку пошуку:
Спочатку шукає кеш-хіти в тій же гілці, що й виконання робочого процесу.
Якщо неуспішно, розширює пошук до батьківської гілки та інших upstream гілок.
Важливо, що доступ до кешу обмежений гілкою, поширюючись на всі робочі процеси та виконання конкретної гілки. Крім того, GitHub вводить політику тільки для читання для записів кешу після їх створення, забороняючи будь-які зміни.
Real-World Implication: From Low to High-Permission Workflow Attack
Ілюстративний сценарій CI демонструє, як зловмисник може використовувати отруєння кешу для ескалації привілеїв з робочого процесу з низькими привілеями до робочого процесу з високими привілеями:
Робочий процес Unit-test, відповідальний за виконання юніт-тестів та інструментів покриття коду, передбачається, що використовує скомпрометований або вразливий інструмент. Цей робочий процес використовує Git action action/cache, що робить кеш доступним для будь-якого робочого процесу.
Робочий процес Release, що відповідає за створення та випуск артефакту програми, оптимізує свої операції, кешуючи залежності Golang.
У цьому сценарії робочий процес unit-test вводить шкідливий запис кешу, замінюючи легітимну бібліотеку логування Golang (`go
Last updated
