I'm reporting three bugs in libmms 0.6.4. All of them are in
interp_asf_header() in src/mms-common-funcs.h, and the input is the ASF
header the MMS server sends during the handshake, so it is fully
attacker-controlled and is parsed on every mms:// or mmsh:// connect
(mms.c:928, mmsh.c:435 and 737).

The parser walks the top-level ASF objects and advances i by each
object's 64-bit length field (i += length, line 282). Three problems:

1. An object with length 0 never advances the loop, and there is no
   timeout on this path: mms_connect() spins at 100% CPU forever. A
   60-byte header triggers it.
2. Same in the inner Header-Extension walk (j += l, line 270). A
   204-byte header.
3. The Stream-Bitrate-Properties case uses the 16-bit stream count
   directly as the loop bound (line 180) with no check against the
   object size or the header size. With 0xFFFF it reads up to about
   393 KB past the end of the object; the mms_t allocation is about
   136 KB total. ASan reports a heap-buffer-overflow READ at
   mms-common-funcs.h:182.

Any program linking libmms (mpd, audacious, xmms2, kget) can be hung
or crashed by a single connect to a malicious mms:// URL, a shared
link, or one entry in a playlist a daemon loads. Doesn't require authentication, one
request.

I tested it end to end on trixie with a small Python script that
speaks the MMS command protocol over TCP and serves a crafted ASF
header. A valid header connects normally; the 60-byte header hangs the
client at 100% CPU; the 58-byte OOB header reliably triggers the
out-of-bounds read, and the distro mpd 0.24.4 (libmms.so.0.0.2) segfaults
when the malicious URL is played (mpc add … && mpc play), the kernel
log shows the fault inside libmms.so.0.0.2. With the hang payload, mpd
stays up but its mms input thread spins at 100% CPU.

I have a minimal fix that I verified (valid headers still parse, all
three PoCs fail cleanly):
- outer walk: replace "if ((i + length) > this->asf_header_len) return;"
  with "if (length < 24 || length > (uint64_t)this->asf_header_len) return;"
- inner walk: add "if (l < 24) break;" after the existing (j + l) > length check
- bitrate loop: "for (j = 0; j < streams && (i + 32 + j * 6) <= this->asf_header_len; j++)"

Upstream has had no release since 2014, so I assume this will need to
go in as a Debian patch. I can send the .patch, a PoC generator and
the repro script.

Given the severity (unauthenticated, deterministic DoS / OOB heap
read), I'd also like to ask whether a CVE could be requested for this.

Thanks,
Adrian Pfeffer