В питонячей либе celery нашли забавную CVE, причем я тоже думал о подобной проблеме когда делал таск на кубок CTF России, и как оказывается недокрутил потенциальную CVE.

Давайте попробую рассказать про что там.

Celery - реализация очереди задач для Python. Основной функционал - возможность создавать и планировать задачи (единица исполнения кода), которые потом могут быть выполнены на другом воркере.

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

Чтобы доставить информацию о задачах на другие машины нужно использовать какое-то внешнее хранилище/брокер, например redis или rabbitmq.

Также celery позволяет хранить информацию о результатах выполнения задачи из коробки в так называемых result backend’ах. Это опять же может быть redis/memcached/бд. [1]

Вопрос, который я задал себе при составлении таска около месяца назад - «а что если мы можем повлиять на хранилище тасков (брокер) или хранилище результатов ?»

Может показаться что такое маловероятно, но достаточно популярный вариант брокера/бэкенда — redis (k-v хранилище).
При этом многие приложения могут использовать редис для кэширования или позволять пользователю хранить там свои данные.
Представить что для простоты деплоя люди будут использовать один и тот же редис для кэширования, хранения данных и celery достаточно легко.

Люди, которые интересуются безопасностью, могут быстро придумать вектор — сериализация (способ кодирования/декодирования объектов в рантайме в байты).

В питоне для сериализации есть очень мощный, но страшный инструмент — pickle. Pickle позволяет сохранить любой питоновский объект в байты, но несет by-design проблему безопасности — десериализовать можно любой объект с мета-поведением, из-за чего при десериализации может быть выполнен произвольный код. [2]

Но разработчики celery прошли этот этап. По-умолчанию в celery используется JSON сериализация. Это накладывает ограничения на объект, который вы можете положить в результат или аргумент задачи, но делает эту историю безопаснее.

Однако вы все еще можете создать свою задачу если имеете доступ к хранилищу задач. Так, если перед вызовом задачи будут какие-то проверки (например права пользователя), то вы сможете их обойти создав свою задачу.

Именно эта идея легла в основу моей задачи на кубок CTF. [3]

А теперь про CVE.

Задача может упасть с ошибкой. Если результатом выполнения задачи будет исключение (exception), то celery честно положит эксепшен в result backend (как строку в случае JSON).

Если приложение захочет получить результат упавшей задачи, то celery прочитает информацию об исключении из брокера и попытается найти/создать тип данных, который задан в строке. [4]

Если немного детальнее, то в случае JSON сериализации в строке будет модуль, тип эксепшена и сообщение.

Передаем модуль - os, тип - system, сообщение - ls.

И celery честно попытается найти модуль os, и сделать вызов конструктора/функции system с аргументом ls.

Красивое RCE.

Fix

В фиксе [5] сейчас проверяется что полученный тип является наследником exception’a или класса ‘type’. Кажется звучит безопасно, но возможно супер-знатоки питона скажут что нет.

[1] https://docs.celeryproject.org/en/stable/getting-started/backends-and-brokers/index.html
[2] https://davidhamann.de/2020/04/05/exploiting-python-pickle/
[3] https://github.com/acisoru/ctfcup-21-quals/tree/main/tasks/web/json-config
[4] https://github.com/celery/celery/blob/c79d5c79c1c212b1f7e5036b7dca18568eae68de/celery/backends/base.py#L405
[5] https://github.com/celery/celery/commit/1f7ad7e6df1e02039b6ab9eec617d283598cad6b