RTCP SR/RR length check ignores the fixed header, report blocks are read past the packet end

Abierto Apto para principiantes
  • ¿Algo no está bien?
#2,229 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
76/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
c
Área
networking

Línea de trabajo

Empieza en daemon/rtcp.c, en la comprobación de longitud de rtcp_Xr(), y compara las estructuras de RR y SR en daemon/rtcp.c y lib/rtcplib.h. Comprueba cómo rtcp_rr_list() utiliza la longitud declarada del paquete y, después, actualiza la comprobación para tener en cuenta el prefijo fijo y los bloques de informes. El trabajo estará terminado cuando se rechacen los ejemplos cortos de RR y SR, mientras que el RR válido siga aceptándose.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

rtpengine version the issue has been seen with

mr26.3.1.2 (3a3ef61), built from the tag, userspace only. The same code is on master at f950a9f.

Used distribution and its version

Debian 13 (container)

Linux kernel version used

6.8.0-90-generic (kernel module not used)

CPU architecture issue was seen on

aarch64

Expected behaviour you didn't see

An SR or RR packet whose report count (RC) does not fit in its declared length is rejected
("Failed to handle or parse RTCP packet type ...").

Unexpected behaviour you saw

rtcp_Xr() compares the packet length with count * sizeof(struct report_block) only. It
leaves out the 8-byte RR prefix (header + SSRC) and the 28-byte SR prefix (header, SSRC and
sender info) that come before the report blocks:

The only other length check is min_packet_sizes, which ensures just the prefix itself
(L454-L456, L683-L690).

rtcp_rr_list() then walks header.count blocks starting after the prefix
(L525-L551), so it can read past the end of the RTCP packet:

  • up to 8 bytes for RR;
  • up to 28 bytes for SR.

The bytes it reads are either the next packet of a compound RTCP packet, or the unused tail of
the receive buffer when the SR/RR is the last packet in the datagram. That tail is the
RTP_BUFFER_TAIL_ROOM slack, so the read stays inside the allocation:

What happens to these bytes:

  • scratch_rr copies them into the receiver-report scratch area, so they go into the SSRC
    stats/MOS (mos_rr), the RTCP log and the HEP JSON (homer_rr):
    L972-L983,
    L1058-L1069.
  • With SSRC translation active, transcode_rr also writes ssrc, number_lost,
    fraction_lost and high_seq_received back into the same block
    (L1296-L1356).
    For an SR, that block can lie wholly past the packet's declared end.

Steps to reproduce the problem

Start rtpengine with --table=-1 --interface=127.0.0.1 --listen-ng=127.0.0.1:2223 --homer=127.0.0.1:9060 --homer-protocol=udp --homer-id=2001, set up a plain RTP/AVP PCMU call with offer and answer over NG, send a few RTP packets each way, then send these from the caller's RTCP port to rtpengine's RTCP port for it. Every datagram ends with the same APP packet (80 cc 00 02, SSRC 0x33333333, name ABCD). Each report block in the test uses SSRC 0x22222222, fraction lost 1, cumulative lost 5, highest sequence 256, jitter 7, LSR 0x0a0a0a0a and DLSR 0x0b0b0b0b, as far as it fits in the packet:

  • RR, length field 5 (24 bytes), RC=1: 81 c9 00 05, SSRC, then 16 bytes.
    • The 8-byte minimum passes, and 24 < 1*24 is false, so the packet is accepted.
    • reports[0] covers bytes 8-31, which is 8 bytes past the end.
  • SR, length field 11 (48 bytes), RC=2: 82 c8 00 0b, SSRC, 20 bytes of sender info, then 20 bytes.
    • The 28-byte minimum passes, and 48 < 2*24 is false, so the packet is accepted.
    • The blocks cover bytes 28-75; the second one lies entirely past the end.

For comparison, a valid RR (length field 7, 32 bytes, RC=1) followed by the same APP packet.

Additional program output to the terminal or logs illustrating the issue

The report blocks in the HEP RTCP JSON that rtpengine sent for each datagram:

valid RR, length 7 (32 bytes):
  81 c9 00 07 11 11 11 11 22 22 22 22 01 00 00 05 00 00 01 00 00 00 00 07 0a 0a 0a 0a 0b 0b 0b 0b | 80 cc 00 02 33 33 33 33 41 42 43 44
  {"source_ssrc":572662306,"highest_seq_no":256,"fraction_lost":1,"ia_jitter":7,"packets_lost":5,"lsr":168430090,"dlsr":185273099}

short RR, length 5 (24 bytes), RC=1:
  81 c9 00 05 11 11 11 11 22 22 22 22 01 00 00 05 00 00 01 00 00 00 00 07 | 80 cc 00 02 33 33 33 33 41 42 43 44
  {"source_ssrc":572662306,"highest_seq_no":256,"fraction_lost":1,"ia_jitter":7,"packets_lost":5,"lsr":2160852994,"dlsr":858993459}

short SR, length 11 (48 bytes), RC=2:
  82 c8 00 0b 11 11 11 11 00 00 00 01 00 00 00 02 00 00 00 03 00 00 00 04 00 00 00 05 22 22 22 22 01 00 00 05 00 00 01 00 00 00 00 07 0a 0a 0a 0a | 80 cc 00 02 33 33 33 33 41 42 43 44
  {"source_ssrc":572662306,"highest_seq_no":256,"fraction_lost":1,"ia_jitter":7,"packets_lost":5,"lsr":168430090,"dlsr":2160852994},
  {"source_ssrc":858993459,"highest_seq_no":0,"fraction_lost":65,"ia_jitter":0,"packets_lost":4342596,"lsr":0,"dlsr":0}

All three are accepted, and no warning is logged.

  • In the short RR, lsr 2160852994 is 0x80cc0002, the APP packet's first word, and dlsr 858993459 is the APP packet's SSRC.
  • In the short SR, the second report block lies entirely past the SR. Its source_ssrc is the APP SSRC, its fraction_lost 65 and packets_lost 4342596 are A and BCD from the APP name, and the rest is read from the receive buffer past the end of the datagram (zeros in this run).

With the check below, the two short packets are rejected with Failed to handle or parse RTCP packet type 201 and ... type 200, they produce no HEP report, and the valid RR is unchanged.

Anything else?

Suggested fix: include the fixed part in the check, for example by passing it into
rtcp_Xr():

  • RR: el->len < sizeof(struct receiver_report_packet) + count * sizeof(struct report_block);
  • SR: the same with sizeof(struct sender_report_packet).
Lenguaje dominante
Perl
Estrellas
992
Forks
459
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de sipwise/rtpengine

Todos los issues de sipwise/rtpengine

Issues similares

Más issues de Perl

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.