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

Aperta Adatta ai principianti
  • Qualcosa non va?
#2,229 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
76/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
c
Ambito
networking

Direzione di ricerca

Inizia in daemon/rtcp.c, al controllo della lunghezza in rtcp_Xr(), e confronta le strutture di RR e SR in daemon/rtcp.c e lib/rtcplib.h. Verifica come rtcp_rr_list() utilizza la lunghezza dichiarata del pacchetto, quindi aggiorna il controllo per tenere conto del prefisso fisso e dei blocchi di report. Il lavoro è completato quando gli esempi RR e SR brevi vengono rifiutati, mentre l’RR valido continua a essere accettato.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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).
Lingua principale
Perl
Stelle
992
Fork
459
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di sipwise/rtpengine

Tutte le issue di sipwise/rtpengine

Issue simili

Altre issue su Perl

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.