Podatności RabbitMQ Java client

Biblioteka kliencka RabbitMQ Java umożliwia aplikacjom Java i JVM łączenie się i interakcję z węzłami RabbitMQ. Przed wersją 5.34.0, AMQConnection.start() stosuje Math.min(maxInboundMessageBodySize, frameMax) po negocjacji Connection.Tune, mimo że AMQP definiuje wartość frameMax zero jako nieograniczoną, a ConnectionFactory.DEFAULT_FRAME_MAX wynosi zero. Gdy wartość domyślna klienta i wartość negocjowana z serwerem są obie zerowe, wynik jest przekazywany do Utils.framePayloadLimit(int), który interpretuje zero jako Integer.MAX_VALUE i wyłącza skonfigurowany limit maxInboundMessageBodySize. Złośliwy serwer AMQP lub atakujący man-in-the-middle zdolny do modyfikacji Connection.Tune i wstrzykiwania ramek do połączenia może następnie wysłać zbyt dużą ramkę dowolnego typu, powodując, że Frame.readFrom() alokuje dużą tablicę bajtów przed walidacją na poziomie treści i potencjalnie kończy proces klienta przez wyczerpanie pamięci. Problem został naprawiony w wersji 5.34.0.

Biblioteka kliencka RabbitMQ Java przed wersją 5.33.1 pozwala na rekurencyjne wywołania ValueReader.readFieldValue dla typów AMQP F i A bez limitu głębokości zagnieżdżenia. Złośliwy serwer AMQP lub pośrednik sieciowy może wysłać około 580 zagnieżdżonych poziomów tabel w ramce connection.start przed uwierzytelnieniem, co powoduje StackOverflowError i zatrzymanie wątku przetwarzania wejścia, prowadząc do odmowy usługi.

Biblioteka kliencka RabbitMQ Java przed wersją 5.33.1 używa ValueReader.readBytes do akceptowania zadeklarowanej długości poniżej Integer.MAX_VALUE i alokuje tablicę bajtów przed sprawdzeniem dostępnych bajtów w ramce. Złośliwy peer AMQP może wysłać pole LongString z typem S i długością taką jak 0x7FFFFFFE, powodując alokację około 2 GB i OutOfMemoryError, co może zakończyć działanie JVM i spowodować odmowę usługi.

Biblioteka kliencka RabbitMQ Java przed wersją 5.33.0 przekazuje wartość javaReturnType z niezaufanej odpowiedzi system.describe do Class.forName z inicjalizacją. Atakujący, który może odpowiedzieć na żądanie JsonRpcClient przez wspólny broker lub przechwycenie sieci, może wybrać klasę już obecną w JVM ofiary i wywołać jej statyczny inicjalizator, co może wpłynąć na poufność, integralność i dostępność procesu klienta.

Biblioteka kliencka RabbitMQ Java umożliwia aplikacjom Java i JVM łączenie się i interakcję z węzłami RabbitMQ. Przed wersją 5.33.0, metody com.rabbitmq.client.ConnectionFactory.useSslProtocol() i ConnectionFactory.useSslProtocol(String) konfigurują com.rabbitmq.client.TrustEverythingTrustManager i pozostawiają wyłączoną weryfikację nazwy hosta, co powoduje akceptowanie dowolnych certyfikatów serwera, w tym certyfikatów samopodpisanych. Atakujący sieciowy, który może przechwycić połączenie TLS, może podszyć się pod brokera RabbitMQ, czytać chroniony ruch AMQP i modyfikować ruch bez weryfikacji certyfikatu lub nazwy hosta. Poprawka zmienia produkcyjne pomocnicze funkcje TLS, aby używały domyślnego magazynu zaufania JVM i włącza weryfikację nazwy hosta, zachowując jawnie nazwany pomocniczy tryb deweloperski bez weryfikacji. Problem został naprawiony w wersji 5.33.0.

Biblioteka kliencka RabbitMQ Java umożliwia aplikacjom Java i JVM łączenie się i interakcję z węzłami RabbitMQ. Przed wersją 5.31.0, przychodzące składanie poleceń AMQP w src/main/java/com/rabbitmq/client/impl/CommandAssembler.java przetwarza metodę zawierającą treść i nagłówek, którego wartość remainingBodyBytes jest mniejsza niż następujący po niej payload AMQP.FRAME_BODY. CommandAssembler.consumeBodyFrame odejmuje kontrolowaną przez peera długość payloadu przed walidacją, że pasuje, co powoduje, że remainingBodyBytes staje się ujemne i zgłasza surowy wyjątek UnsupportedOperationException zamiast MalformedFrameException. Złośliwy lub skompromitowany broker może wysłać tę nieprawidłową sekwencję na otwartym niezerowym kanale, aby zakończyć przetwarzanie ramek i zamknąć połączenie klienta, powodując odmowę usługi dla pracy korzystającej z tego połączenia. Problem został naprawiony w wersji 5.31.0.

Biblioteka kliencka RabbitMQ Java przed wersją 5.33.0 nie stosuje spójnie negocjowanego limitu frame_max podczas walidacji rozmiaru ramek od brokera. Złośliwy broker może wysłać ramkę większą niż dozwolona, co prowadzi do alokacji i dekodowania nieprawidłowej ramki zamiast jej odrzucenia, powodując przerwanie połączenia i odmowę usługi po stronie klienta.