Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    • Switch to GitLab Next
  • Sign in / Register
  • wireshark wireshark
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 1,342
    • Issues 1,342
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 151
    • Merge requests 151
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • External wiki
    • External wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Wireshark Foundation
  • wiresharkwireshark
  • Issues
  • #17813
Closed
Open
Created Dec 29, 2021 by Sharon Brizinov@sean007Contributor

RTMPT dissector inf loop - 100% cpu - denial of service

Summary

It is possible to reach an infinite loop in the RTMPT dissector by generating a specifically crafted RTMP packet due to int underflow vulnerability in the AMF parsing part of the dissector. The packet will consume 100% core cpu, which eventually lead to a denial of service via packet injection or crafted capture file.

I believe that the bug was introduced to the code following this commit - #5351 (comment 400649448)

If that's true, it means that the bug exists for approximately 11 years over many tshark releases.

Technical details

Real-Time Messaging Protocol (RTMP) is a communication protocol for streaming audio, video, and data over the Internet which was mainly used by Flash Player. RTMP is a binary protocol over tcp port 1935.

The protocol enables to encode Action Message Format (AMF) data and the parsing of AMF object is mainly done by the rtmpt_get_amf_param or rtmpt_get_amf_txid functions. Before parsing AMF param, it is needed to understand its size. Therefore, rtmpt_get_amf_length is called to get the item param size. However, it is possible to reach an infinite loop condition within rtmpt_get_amf_length by carefully crafting AMF message as follows: The function has a main while loop with the following conditions: while (rv == 0 || depth > 0) so we need to make sure rv == 0. In the first round all variable are initialised to 0. wireshark___packet-rtmpt_c

The first meaningful line reads the object type: iObjType = tvb_get_guint8(tvb, offset+rv); Since we control the data, we can encode a speicifc object type that has a dynamic size. For example - AMF0_STRING (+3) or AMF0_XML (+5). These types allow to read the item length from the buffer using tvb_get_ntohl. However, itemlen is defined as a signed int gint, which means we can cause an int underflow by providing a size such as 0xfffffffd (-3) 0xfffffffb (-5). Then, since itemlen will remain zero, the loop will repeat itself because rv is affected by the itemlen: rv += itemlen; and so rv will remain zero forever and the loop will continue forerver.

wireshark___packet-rtmpt_c

Relevant functions: rtmpt_get_amf_txid --> rtmpt_get_amf_length

Steps to reproduce

Open the provided pcaps with tshark/wireshark poc

What is the current bug behavior?

Wireshark/tshark will be stuck in an endless loop due to an int underflow bug.

What is the expected correct behavior?

Wireshark/tshark shouldn't be stuck in an endless loop.

Sample capture file

Attached poc

Relevant logs and/or screenshots

poc

Build information

Version 3.6.0 (v3.6.0-0-g3a34e44d02c9) 
Edited Dec 29, 2021 by Sharon Brizinov
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking