Две недели назад была обнаружена критическая уязвимость в библиотеке 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), большого специалиста по архиваторам.
