000Две недели назад была обнаружена критическая уязвимость в библиотеке Lempel-Ziv-Oberhumer (LZO), которая используется во многих приложениях, в том числе в ядре Linux, различных файловых системах, Android, OpenVPN, автомобилях, самолётах и т.д. Правда эксплойт можно было сделать для небольшого числа 32-битных систем, но всё равно впечатляет тот факт, что баг присутствовал в LZO аж с 1994 года и унаследован в разных вариациях библиотеки, в том числе в последней LZ4.

Автор выпустил патч, закрывающий уязвимость. Однако, наличие такой дыры привлекло внимание общественности к исходному коду. Вскоре в LZ4 обнаружили ещё один баг. В некоторых редких ситуациях LZ4 может предоставлять доступ к произвольным участкам оперативной памяти, что может привести к проблемам безопасности на отдельных архитектурах. Фактически, это та же уязвимость, что и раньше, просто прошлый патч не полностью устранил её.

Напомним, баг в этом коде был связан с тем, что переменная t используется в качестве параметра для установки размера буфера памяти.

66 copy_literal_run:
67 #if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
68             if (likely(HAVE_IP(t + 15) && HAVE_OP(t + 15))) {
69                     const unsigned char *ie = ip + t;
70                     unsigned char *oe = op + t;
71                     do {
72                             COPY8(op, ip);
73                             op += 8;
74                             ip += 8;
75                             COPY8(op, ip);
76                             op += 8;
77                             ip += 8;
78                     } while (ip < ie);
79                     ip = ie;
80                     op = oe;
81             } else
82 #endif

В режиме безопасного разархивирования есть детектор фрагментов неархивируемого оригинального содержимого (Literal Run). Если встречается нулевой байт, то переменная t из приведённого листинга увеличивает своё значение на 255. Переменная может увеличиться до очень большого числа. Скажем, если t представляет собой 32-битное число, то требуется 16 мегабайт нулевых байтов, чтобы вызвать переполнение буфера.

Новая уязвимость присутствует лишь в 32-битных системах и её трудно эксплуатировать на практике. В реальности, она представляет угрозу только на ARM-системах. Тем не менее, в 32-битных приложениях лучше обновить библиотеку до версии r199, где проблема полностью решена.

Подробный анализ уязвимости см. в блоге Янна Коллета (Yann Collet), большого специалиста по архиваторам.



Оставить мнение