MongoDB выпустила исправления для клиентской библиотеки C Driver. Версии 1.30.15 и 2.5.8 закрывают уязвимости в разборе сжатых ответов сервера и в скачивании файлов из GridFS. Одна из них ведёт к утечке памяти. Другая обрывает работу приложения.
Утечка памяти при разборе сжатых ответов
При этом затронуты приложения, которые подключаются к MongoDB через эту библиотеку. В трекере указаны затронутая ветка 1.24.0 и все версии до 1.30.15 и до 2.5.8. У утечки памяти приоритет Major (P3). У аварийного завершения приоритет Minor (P4).
Первая уязвимость идёт под номером SECBUG-6159 во внутренней системе учёта. Номер CVE в материалах отсутствует. Из-за этого сканеры могут не показать проблему. Версию библиотеки надёжнее проверять вручную.
Ответы сервера приходят в виде сообщений OP_COMPRESSED. Именно так в протоколе MongoDB помечается сжатое содержимое. Клиент распаковывает его перед разбором. Если распаковка срывается, функция обработки оставляла выходные параметры незаполненными. Из-за этого выделенная память не освобождалась.
Утечка накапливается, пока процесс работает. Клиентская библиотека живёт в приложении долго, поэтому редкие сбои складываются. В результате растёт потребление памяти, хотя полезной работы не прибавляется. Перезапуск по расписанию скрывает симптом, но причину не убирает.
Косвенным признаком утечки служит рост памяти без роста нагрузки. Помогает регулярный замер потребления процесса. Если приложение работает неделями без перезапуска, сбой проявляется постепенно. Мониторинг памяти покажет такую динамику раньше, чем откажет сервис.
Что меняет исправление
Разработчики изменили обработку ошибок распаковки. После этого выходные параметры сбрасываются в пустое значение и нулевую длину при любом сбое. Кроме того, из кода убрали лишнее освобождение буфера. Разработчики также дополнили тесты проверкой состояния после ошибки. Поведение всех вызовов привели к единому виду.
Атака возможна по сети. Учётные данные при этом не нужны, участие пользователя тоже не требуется. Достаточно ответа, который клиент не может распаковать. Поэтому уязвимость важна там, где клиент соединяется с недоверенным сервером.
Аварийное завершение при скачивании из GridFS
GridFS хранит крупные файлы внутри MongoDB. Файл делится на части, а метаданные при этом лежат в отдельной коллекции. Функция скачивания в поток читает эти метаданные перед выдачей данных. Такой путь используют приложения, которые отдают пользователям большие файлы.
Если метаданные повреждены, разбор завершается неудачей. Старая версия библиотеки в этом случае прерывала процесс целиком. Вместо возврата ошибки приложение падало. Кроме того, вызывающий код не получал кода ошибки.
Пострадать может сервис, который принимает файлы от внешних пользователей. Загрузка с испорченными метаданными приводит к остановке обработки. В результате падает весь процесс, а не отдельный запрос. Восстановление требует перезапуска и повторной выдачи данных.
Исправление добавляет проверку входных данных. При пустом потоке выгрузки библиотека возвращает ошибку. Добавлены тесты на такие сценарии. В результате сбой остаётся ошибкой уровня вызова, а не аварией приложения.
После обновления клиент ведёт себя предсказуемо при ошибках. Память возвращается системе, а вызывающий код получает понятный статус. В результате исчезает класс сбоев, который приводил к авариям. Для администратора это значит, что проверка версии даёт результат.
Что делать администраторам
Обновиться стоит до 1.30.15 или 2.5.8. Исправления вышли для веток 1.30 и 2.5. В списке затронутых есть ветка 1.24.0. Однако обходных мер вендор не описал. Сведений об эксплуатации в реальных атаках в трекере нет.
При этом сжатие трафика и приём файлов от пользователей встречаются почти в каждом проекте. Поэтому обновление библиотеки стоит планировать вместе с ближайшим релизом приложения. Также версию можно проверить в манифесте зависимостей. После обновления эти сбои не воспроизводятся.
Ссылки
