🇰🇷 한글 설명
RabbitMQ의 특정 버전에서 패턴을 정규식으로 변환할 때 중첩된 게으른 수량자(lazy quantifiers)로 인해 백트래킹이 발생하는 취약점입니다. 인증된 AMQP 1.0 사용자가 정교하게 조작된 LIKE 필터를 사용하여 스트림 큐에 메시지를 전달할 경우, CPU 자원을 과도하게 소모하게 만드는 CPU 증폭 공격이 가능합니다.
💡 쉬운 설명
공격자가 특수한 규칙을 사용하여 메시지를 보내면, 서버가 이를 처리하는 과정에서 계산을 너무 많이 하게 만들어 컴퓨터를 느리게 만듭니다. 이는 마치 복잡한 미로 찾기를 반복하게 하여 컴퓨터의 힘을 낭비하게 만드는 것과 같습니다.
🇺🇸 원문 (English)
RabbitMQ is a messaging and streaming broker. Prior to versions 4.2.7 and 4.3.1, pattern_to_regex maps % -> .*? and _ -> ., then compiles ^...$ with only [unicode]; re:run is called with only [{capture, none}] - no explicit match_limit. A pattern like %_%_..._%X becomes ^.*?..*?.....*?.X$ with overlapping lazy quantifiers. The whole-expression cap is ?MAX_EXPRESSION_LENGTH=4096 chars / ?MAX_TOKENS=200; a LIKE string literal is one token, so ~2000 %_ pairs fit. SQL filters are accepted unconditionally at rabbit_amqp_session.erl:3264 (no feature flag). Evaluated per-message at rabbit_stream_queue.erl:1439. OTP's default 10M match_limit caps each match at ~100-200 ms (not seconds), and the re NIF yields to the scheduler. An authenticated AMQP 1.0 consumer with read+write on a stream queue can cause ~100-200 ms of CPU per delivered message via a crafted LIKE filter, multiplied across thousands of messages and parallel sessions - a substantial backtracking-driven CPU amplification. Preconditions include AMQP 1.0 with stream queues in use Attacker can attach a receiver with a filter (read permission) and publish messages with long property values (write permission). This issue is fixed in versions 4.2.7 and 4.3.1.
📍 영향받는 시스템
RabbitMQ 4.2.7 및 4.3.1 미만 버전
⚔️ 공격 벡터
인증된 AMQP 1.0 사용자가 스트림 큐에 조작된 LIKE 필터와 긴 속성 값을 가진 메시지를 전송하여 CPU 부하 유도
🛡️ 대응 방법
RabbitMQ를 4.2.7 또는 4.3.1 이상의 버전으로 업데이트하십시오.
🔧 검증 코드
출력된 버전 번호가 4.2.7 또는 4.3.1보다 낮은지 확인하십시오.
rabbitmqctl version 2>/dev/null || rabbitmq --version 2>/dev/null