u/Prize-Unlucky

New public disclosure: MAILDROP-01

Apple's Maildrop attachment service generates icloud.com URLs with three unsigned, client-controlled parameters:

- f= — filename shown on the landing page, AND interpolated as ${f} in the CDN download path

- sz= — file size shown on the landing page

- uk= — user key (no binding between it and the other params)

Change f= and sz=, share the link. The icloud.com landing page shows your chosen filename, your chosen file size, and the icon Maildrop infers from your chosen extension. The CDN serves the file with Content-Disposition: attachment; filename="<your chosen name>".

Everything on Apple's domain. No visual indicator that the metadata is sender-controlled.

Reported 7 July 2023. Status as of 8 April 2026: "Prioritised for review". No remediation deployed. Time elapsed: 34 months.

Full technical write-up, Python PoC, and fix recommendations:

https://stuart-thomas.com/research/maildrop-spoofed-params/

Vendor ref: OE1950888220

Published two Apple disclosures today (links below). Both confirmed by Apple, both scheduled for "Fall 2026" — six months from filing. I also wrote up the reasoning behind publishing ahead of that window, because I think the reasoning should be on the record.

The essay covers:

- The implicit contract between researchers and vendors, and what "honouring it in letter but not in spirit" looks like in practice

- What "Fall 2026" actually means for a one-line bounds check fix

- The 90-day norm, why it exists, and what Project Zero's own data shows about fix times under deadline vs. indefinite windows

- The structural incentive misalignment when a bounty is "pending review" for months — that's not a bounty programme, that's a hush arrangement with a variable payout

- The specific calculus behind each disclosure: both bugs confirmed, both locally/conditionally exploitable only, mitigations available now, fix complexity low

It's not a rant. It's a record.

https://stuart-thomas.com/vendor-ethics/

---

The two disclosures:

- PING-01 (BSS write): https://stuart-thomas.com/research/ping-sweepmax-bss/

- SMB-01A (64 GiB amplification): https://stuart-thomas.com/research/smbd-copychunk-dos/

The -s flag in /sbin/ping has a maxpayload bounds check. -G sweepmax doesn't. An #ifndef __APPLE__ block removed the original uid guard without adding an equivalent check, so the fill loop walks past the end of the 65,535-byte outpackhdr[] BSS global and into adjacent globals.

The write is byte-precise and deterministic: byte at offset N gets value (N-1) % 256, fully controlled by -G.

Empirically confirmed on macOS 26.4.1 arm64e:

- sweepmax=65637: overwrites the static int s socket fd at BSS+128 with 0x63. Every subsequent setsockopt() returns EBADF. Exit 71.

- sweepmax=65636: runs clean. Binary-searchable threshold, invariant across runs.

At higher sweepmax values the loop reaches pointer-type globals (*outpack, *hostname, *shostname). On x86_64 that's a write-what-where bounded by the sequential value constraint. On arm64e, PAC blocks code-pointer hijack; state corruption is still demonstrable.

ping isn't setuid on macOS 11+, so no direct priv-esc. Local only.

Fix is one line — symmetric maxpayload check matching what -s already does.

Apple confirmed 16 April 2026, fix scheduled Fall 2026. Source is open: github.com/apple-oss-distributions/network_cmds

Full write-up with memory dump evidence:

https://stuart-thomas.com/research/ping-sweepmax-bss/

Apple's /usr/sbin/smbd (not Samba — Apple's own implementation) processes FSCTL_SRV_COPYCHUNK without enforcing any of the three limits MS-SMB2 §3.3.5.15.6 requires:

- MaxChunkCount: 256 → accepted 65,535 chunks

- MaxChunkSize: 1 MiB → accepted 1,048,577 bytes

- MaxDataSize: 16 MiB → accepted ~17 MiB

All three tests returned STATUS_SUCCESS. The spec requires STATUS_INVALID_PARAMETER.

Attack: one authenticated SMB session, one 256-byte IOCTL, smbd runs 65,535 × (read_file(1MiB) + write_file(1MiB)) = 64 GiB disk I/O. The allocator retry loop means it doesn't fail cleanly — it just keeps going.

Default macOS isn't exposed (File Sharing off by default). If you have SMB sharing enabled, mitigations are in the disclosure.

Disassembly shows the chunk_count extraction landing unmodified in the parsed struct (no bounds check), and the copy loop with a cbz-only guard (bail if zero, no cmp against 256).

CVSS 3.1: 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Apple confirmed 25 April 2026, fix scheduled Fall 2026.

Full write-up with disassembly, runtime captures, and PoC:

https://stuart-thomas.com/research/smbd-copychunk-dos/

Spent 2024–2025 filing Apple Security Bounty reports. All 16 are now closed. I've written up every one — including the ones Apple were right to reject, the ones where my own PoC was lying to me, and the few where I couldn't bridge the gap between binary evidence and a working exploit. No hype, no CVE-farming.