Недавно мы писали про уязвимости Apache Kafka, обнаруженные и исправленные в 2023 и 2022 гг. Сегодня рассмотрим, как одна из них устранена в отладочном релизе 3.5.1, опубликованного 21 июля 2023 года. А также познакомимся с другими улучшениями и исправлениями ошибок этого выпуска.
Обновления Apache Kafka 3.5.1
Релиз Apache Kafka 3.5.1 не случайно считается отладочным. В нем нет ни одной новой фичи и исправлено всего 8 ошибок. Одна из них связана с уязвимостью CVE-2023-34455, когда клиенты, использующие кодек сжатия snappy, могут вызвать ошибку нехватки памяти на брокерах. Проблема заключается в библиотеке snappy-java и потенциально может быть использована для генерации OOM-ошибки, что приводит к отказу в обслуживании (DoS) на брокере Kafka. Уязвимость позволяет любому пользователю, который может передавать данные брокеру, использовать уязвимость, отправляя вредоносную полезную нагрузку в записи, сжатой с помощью кодека snappy. Кодек snappy-java — это быстрый компрессор/декомпрессор для Java. Получив запись, брокер попытается распаковать запись, чтобы выполнить проверку записи, и делегирует распаковку библиотеке snappy-java. Уязвимость в пакете snappy-java может привести к выделению неожиданного объема памяти кучи, что вызовет ошибку OOM в брокере. событий.
Из-за использования непроверенной длины фрагмента в версиях snappy до 1.1.10.1 может возникнуть неисправимая фатальная ошибка. Код в функции hasNextChunk в файле SnappyInputStream.java проверяет, есть ли в данном потоке дополнительные фрагменты для чтения. Он делает это, пытаясь прочитать 4 байта. Если не удалось прочитать 4 байта, функция возвращает false. Иначе, в случае доступности этих 4 байтов, код рассматривает их как длину следующего фрагмента. Когда переменная compressed имеет значение null, выделяется массив байтов с размером, заданным входными данными. Поскольку код не проверяет законность переменной chunkSize, можно передать отрицательное число, например, 0xFFFFFFFF, равное -1, что вызовет исключение java.lang.NegativeArraySizeException. Наиболее негативный результат может произойти при передаче огромного положительного значения, например, 0x7FFFFFFF, что вызовет фатальную ошибку java.lang.OutOfMemoryError, т.е. нехватку памяти.
Эта уязвимость затрагивает версии Kafka с 0.8.0 до 3.5.0. На устранение этой проблемы и направлено обновление Kafka 3.5.1 с библиотекой snappy-java версией выше 1.1.10.1 от 5 июля 2023 г., которая обратно совместима со всеми уязвимыми версиями платформы потоковой передачи.
Другим важным исправлением Kafka 3.5.1 является регрессия для проверки security.protocol, начиная с 3.3.0. Изначально эта ошибка была вызвана добавлением валидаторов для конфигураций продюсера и потребителя (key.serializer, value.serializer, key.deserializer, value.deserializer), связанных с сериализацией и десериализацией. В результате добавления валидатора недопустимости Null-значений конфигурация security.protocol допускала только значения верхнего регистра, такие как PLAINTEXT, SSL, SASL_PLAINTEXT, SASL_SSL. До этого изменения также поддерживались строчные значения (sasl_ssl, ssl). Но начиная с Apache Kafka 3.3.0, внутри SecurityProtocol значения нижнего регистра перестали поддерживаться, выдавая ошибку. В выпуске 3.5.1 это устранено: свойства конфигурации снова стали нечувствительны к регистра, допуская прописывать из значения как заглавными, так и строчными буквами.
Также в выпуске исправлена задержка Fetch-запроса, которая не обновлялась при простаивающем разделе. Поле задержки PartitionFetchState устанавливается в None при создании состояния и обновляется при получении байтов для раздела. Для простаивающих разделов, в т.ч. вновь созданных, задержка никогда не обновлялась, потому что параметр validBytes не был положительным, т.е. условие validBytes > 0 не бывало истинным. Побочным эффектом этого становится рассинхронизация раздела и его некорректная обработка.
Еще одним важным исправлением стало удаление authorizer.class.name перед выполнением миграции с внешнего сервиса синхронизации метаданных Apache Zookeeper на KRaft. Ранее из-за этого возникало фатальное исключение java.lang.IllegalArgumentException, приводящее к сбою брокера Kafka. Также исправлена ошибка, из-за которой RPC-вызовы UMR и LISR не отправлялись в режиме двойной записи при наличии новых разделов в топике. При миграции с Zookeeper на KRaft сохраняются ссылки как на новые, так и на измененные сопоставления разделов из экземпляра TopicsDelta. Изменение changePartitions может привести к изменению экземпляра TopicsDelta , который предоставляется в качестве входных данных для метода. При выполнении запросов UMR и LISR, которые нужно сделать в MigrationPropagator.sendRPCsToBrokersFromMetadataDelta, Zookeeper пишет, что TopicsDelta потерял метаданные измененных разделов. Сейчас это исправлено.
Устранена еще одна достаточно значимая ошибка, связанная с регистрацией длинных записей в логах KRaftControllerChannelManager. Например, когда брокер не работает, регистрируется предупреждение (WARN), которое включает в себя весь запрос (UpdateMetadataRequest или LeaderAndIsrRequest). Для больших кластеров это могут быть очень большие запросы, что потенциально может привести к избыточному выводу данных в журналах библиотеки логирования log4j, которая часто становится источником уязвимостей, о чем мы писали здесь и здесь.
Еще одной исправленной в релизе 3.5.1 ошибкой стало устраненное повторной обработки записей, отфильтрованных SMT-преобразователем, с помощью AbstractWorkerSourceTask. Напомним, преобразователь отдельных сообщений (SMT, Single Message Transformation) используется для применения к сообщениям из топика Kafka по мере их прохождения через платформу Connect. SMT преобразуют входящие сообщения после их создания коннектором источника, но до того, как они будут записаны в Kafka. SMT преобразуют исходящие сообщения перед их отправкой на коннектор приемника.
Если исключение повтора RetriableException вызывается клиентом администратора или клиентской операцией продюсера в AbstractWorkerSourceTask::sendRecords , операция отправки повторяется для оставшихся записей в пакете. В логике вычисления оставшихся записей в пакете есть ошибка, которая приводит к повторной обработке записей, отфильтрованных цепочкой преобразования задачи. Это также приведет к тому, что метод SourceTask::commitRecord будет вызываться дважды для одной и той же записи, что может привести к сбою некоторых типов коннекторов источника. Эта ошибка существует с тех пор, как SMT были впервые представлены в версии фреймворка 0.10.2. В релизе Apache Kafka 3.5.1 это исправлено.
Наконец, исправлена незначительная ошибка StorageTool, когда справочное сообщение не совсем корректно отображало настройку пользовательского параметра при создании записи SCRAM для начальной загрузки. Ранее StorageTool принимало имя пользователя вместо имени параметра. В результате внутри записи все тесты, использующие StorageTool, использовали пользователя в качестве параметра, создавая KafkaPrincipals с таким названием. Но создание учетных данных SCRAM выполняется с помощью флага—entity-name. В Apache Kafka 3.5.1 это разночтение устранено.
Освойте администрирование и эксплуатацию Apache Kafka для потоковой аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
- Apache Kafka для инженеров данных
- Администрирование кластера Kafka
- Администрирование Arenadata Streaming Kafka
Источники
