# Exploiting The Sonos One Speaker Three Different Ways: A Pwn2Own Toronto Highlight

Three Pwn2Own teams chained info leaks and UAF/stack-overflow bugs in Sonos One's anacapad daemon and libsmb2 to achieve unauthenticated RCE.

- Payout: $105,000
- Severity: high
- Program: Sonos
- Credited: The ZDI Research Team
- Disclosed: 2023-05-25
- CVE: CVE-2023-27352, CVE-2023-27353, CVE-2023-27354, CVE-2023-27355
- Write-up quality: 8/10
- Original: https://www.zerodayinitiative.com/blog/2023/5/24/exploiting-the-sonos-one-speaker-three-different-ways-a-pwn2own-toronto-highlight
- Library page: https://bugbountylibrary.com/r/blog%3Azerodayinitiative-com-blog-2023-5-24-exploiting-the-sonos-one-speaker-three-different-ways-a-pwn2own-toronto-highlight
- Tags: domain:iot domain:network impact:rce kind:bounty platform:blog sev:high technique:chained technique:source-review vuln:info-disclosure vuln:memory-corruption vuln:rce

**Target:** Sonos One speaker anacapad daemon (libsmb2, /msprox SOAP proxy, MPEG-TS parser)
**Root cause:** libsmb2 leaves a dangling smbdir pointer in the wait_queue when a reply carries an invalid message_id, and the MPEG-TS parser trusts an attacker-controlled afelen field without bounds checking.
**Steps:**
1. Act as a malicious SMB server reachable by the speaker; add an SMB share via the device command interface.
2. Reply to smb2QueryDirectory with a malformed PDU whose output buffer offset exceeds the PDU length to leak libc/heap addresses (CVE-2023-27354).
3. Reply with an invalid message_id so the PDU stays in wait_queue holding a dangling dir pointer; smb2_closedir frees dir.
4. On smb2_disconnect_share, reply to the tree-disconnect with a Query Directory response reusing the original MID and append padding to reclaim the freed smbdir, overwriting smbdir->cb.
5. Trigger pdu->cb to gain $PC control and ROP to shell.
6. Alternatively, send a .ts file with oversized afelen to overflow the stack in the MPEG-TS parser (CVE-2023-27355), using leaked canary/base to overwrite return address and jump to exec() wrapper with x19/x22 pointing at a command buffer.
**How found:** Code review of anacapad and libsmb2: noticed snprintf return value used unchecked as header length, missing offset-vs-PDU-length check in smb2_process_query_directory_fixed, and that smb2_fetchfiles_async keeps a dir pointer in wait_queue that survives smb2_closedir when message_id mismatches.
**Exploitation:** Attacker on the same network runs a rogue SMB server (modified impacket) and/or rogue Sonos speaker. Info leaks (libsmb2 OOB read, /msprox snprintf OOBR) yield libc, heap, stack canary, stack and .text addresses. UAF in libsmb2 gives $PC control via reclaimed smbdir->cb, then ROP to shell; or MPEG-TS stack overflow overwrites return address to exec() wrapper for arbitrary command execution.
**Escalation:** Chained info leak (CVE-2023-27354 or CVE-2023-27353) with UAF (CVE-2023-27352) or stack overflow (CVE-2023-27355) to bypass ASLR/canary and reach RCE.
**Insight:** In async SMB client libraries, a reply with a mismatched message_id leaves the PDU alive in the wait queue holding a pointer to a struct the caller frees on error—reclaim that struct via attacker-controlled padding in a later reply to hijack the callback pointer.