graypixel2121/cve-2025-61228Technical analysis and proof-of-concept exploit for CVE-2025-61228, a privilege escalation vulnerability in SuperDuper!'s auto-update mechanism, with detailed breakdown of the attack vector and mitigation guidance.
This issue appears to be worse than the developer suggests, so I don't want this part to be lost in the weeds. The developer noted on their blog:
This can only happen if a program running on your system is looking for SuperDuper to perform an update, a real update is presented through legitimate means, and you click Upgrade.
This is not actually true, exploiting this vulnerability does not require a real update to be presented through legitimate means. Never, ever accept an update provided by SuperDuper 3.10 and older! I explain this in more detail below.
It's also important to understand that this vulnerability is not limited to privilege escalation, rather it also involves a subversion of privacy controls. That detail seems to have been omitted from the developer's blog post.
From the developer's blog:
Our auto-update mechanism can be hijacked and convinced to install a package that isn't SuperDuper.
Even though we signed and notarized our installer package, Gatekeeper is not checking that notarization when installed by macOS's package installer. As such, the download could be changed, and we'd install that instead. Since the install is being done with escalated privileges, that could allow a malicious 3rd party's program, which you would also have to install, to gain administrator access to your system.
From the CVE:
An issue in Shirt Pocket SuperDuper! V.3.10 and before allows a local attacker to execute arbitrary code via the software update mechanism
This author is not the discoverer of the vulnerability, who is identified by the SuperDuper developer as "anonymous security researcher". I claim no credit for discovering this vulnerability, I just took some interest in doing a technical analysis of it.
CVSS 3.1 Score: 7.8 High (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
To avoid this vulnerability, either delete the SuperDuper! application, or apply the 3.11 update.
Warning: You must download the update directly from the developer's website to avoid this vulnerability.
This exploit analysis and proof of concept is provided for educational purposes only. Use it at your own risk.
Rather than implementing an open source software update solution that has been tested by hundreds of developers and security professionals, the SuperDuper developers created their own software update mechanism built atop insecure shell scripts that run with root privileges and have full disk access. By failing to authenticate the software that is getting installed during the update, SuperDuper is duped into installing an attacker's software. The developer's fix addresses only the authentication aspect of this vulnerability, it does not address the inherent vulnerabilities that result from using shell scripts to facilitate the update process.
The developer's "Gatekeeper is not checking that notarization" comment is misleading. GateKeeper comes into play when you attempt to open something that was downloaded in a browser, but that is not applicable in an application's internal software update mechanism. It is 100% the developer's responsibility to validate anything that their software downloads and installs onto your computer – don't let this developer fool you into believing this is a failure of GateKeeper. Getting to the heart of the exploit, an attacker can dupe SuperDuper into installing an alternate package, and that happens with escalated privileges. Presumably it would also run with full disk access too, because SuperDuper requires full disk access to do anything at all.
The developer's blog also states:
This can only happen if a program running on your system is looking for SuperDuper to perform an update, a real update is presented through legitimate means, and you click Upgrade.
With that comment, I assumed that it would probably not be possible to reproduce this exploit because it should involve server-side changes to the update mechanism which would have been made alongside the post of the 3.11 patch. In other words, in order to prevent older versions of the software from being affected by this vulnerability, surely they have disabled the update mechanism, right? Well... I downloaded an older version of SuperDuper, and when I opened it, I was immediately greeted with an update notification† – one click away from potential exploit. I found this to be very intriguing – how will anyone using an older version of the application be protected from this vulnerability if the auto-update mechanism is not disabled? (this is related to the "alert" I mentioned at the top of this article, I'll revisit this question at the end)
† Kind of... The result was actually very awkward. There was no description of the update nor security advisory, the window was just blank with a Skip and Update button. So older users are not only not protected from the exploit by having the update mechanism disabled, but they are also not informed of the problem via the update mechanism.
I forged ahead. When you apply the upgrade, the backend mechanics are helpfully logged to the SuperDuper log, so we'll start there to see how it works:
Transcript : UpgradeTranscript.plist
Ext Logging : Disabled
PHASE: 1. Upgrade Application
...ACTION: Downloading upgrade package
......COMMAND => Downloading update package...
......COMMAND => Preparing update package
...ACTION: Installing upgrade package
......COMMAND => Preserving SDAgent owner and mode bits
......COMMAND => Installing upgrade package
installer[3148] <Debug>: Product archive /tmp/SuperDuper!.pkg trustLevel=350
Many Mac apps that live outside of the Mac App Store use the open source Sparkle framework to (securely) manage software updates. Not SuperDuper. We can see here that they created their own, and this is a great example of why that's often a bad choice. Software upgrade mechanisms are prime targets for exploits, so they require a lot of time and expertise to keep them secure. "UpgradeTranscript.plist" is a reference to a file inside of the SuperDuper application which spells out a series of Terminal commands that SuperDuper uses to download and apply the update:
cat /Applications/SuperDuper\!.app/Contents/Resources/Transcripts/UpgradeTranscript.plist
<?xml version="1.0" encoding="UTF-8"?>
...
/usr/bin/curl SDHTTPproxy.Host --silent --show-error --output /tmp/superduper.tar.gz -L SDdownloadURL
cd /tmp; if [ -d superduper_install ]; then /bin/rm -rf superduper_install; fi; /bin/mkdir superduper_install; /usr/bin/tar xzf superduper.tar.gz; /bin/rm /tmp/superduper.tar.gz; if [ -d '/Library/Receipts/SuperDuper!.pkg' ]; then /bin/rm -rf '/Library/Receipts/SuperDuper!.pkg'; fi;
/usr/sbin/installer -allow -verboseR -dumplog -pkg '/tmp/SuperDuper!.pkg' -target / >&1 2>&1;
if [ ! -d '/tmp/superduper_install/SuperDuper!.app' ]; then /usr/bin/ditto -rsrc '/Applications/Utilities/SuperDuper!.app' '/tmp/superduper_install/SuperDuper!.app'; fi
/bin/rm -rf '/tmp/SuperDuper!.pkg' '/tmp/superduper_install' '/Library/Receipts/SuperDuper!.pkg'; if [ SDAppBundle.'Path != '/Applications/Utilities/SuperDuper!.app' -a -d '/Applications/Utilities/SuperDuper!.app' ]; then /bin/rm -rf '/Applications/Utilities/SuperDuper!.app'; fi
I see at least four problems with these commands and procedure: