GHSA-hg88-v3cw-3qrh Sparkle: Binary delta apply intermediate-symlink traversal in malicious .delta

• SwiftURL github.com/sparkle-project/Sparkle: < 2.9.2 → fixed in 2.9.2

Summary Binary delta apply intermediate-symlink traversal in malicious .delta `Autoupdate/SUBinaryDeltaApply.m` enforces `relativePath.pathComponents containsObject:@".."` and rejects writes whose immediate parent directory IS itself a symbolic link, but does not detect symlinks deeper in the relative path. `Autoupdate/SPUSparkleDeltaArchive.m`'s `extractItem:` will create symlinks in the destination tree from archive content (no `..` check on the symlink target), and a subsequent `Extract` item targeting `/foo/bar` then escapes the destination tree via `fopen(path, "wb")` because the kernel resolves the intermediate symlink during the open call. This is a defense-in-depth issue: exploitation requires a maliciously-crafted `.delta` that passes EdDSA signature verification, i.e. EdDSA private-key compromise. With the AppInstaller running as root for system-domain installs, it gives the holder of a stolen signing key arbitrary file write at root level via the delta-apply path, which is a strictly broader primitive than the "drop-in replacement bundle" install they would otherwise have. Affected versions: 1.x (master branch), 2.x branch including 2.9.1. Details Symlink writeable from archive `Autoupdate/SPUSparkleDeltaArchive.m:557-678`'s `extractItem:` handles symlinks if the archive item carries `S_ISLNK(mode)`: ```objc } else { // Link files if (PARTIAL_IO_CHUNK_SIZE PATH_MAX) { ...too long... } char buffer[PATH_MAX + 1] = {0}; if (![self _readBuffer:buffer length:(int32_t)decodedLength]) { ... } NSString *destinationPath = [fileManager stringWithFileSystemRepresentation:buffer length:decodedLength]; [fileManager removeItemAtPath:itemFilePath error:NULL]; NSError *createLinkError = nil; if (![fileManager createSymbolicLinkAtPath:itemFilePath withDestinationPath:destinationPath error:&createLinkError]) { _error = createLinkError; return NO; } ... lchmod(itemFilePathString, mode); } ``` The link's `destinationPath` is taken verbatim from the archive content with only a length cap; absolute paths and `..` are accepted. After this item is processed, the destination tree contains a symlink that points outside it. Parent-symlink check is shallow `Autoupdate/SUBinaryDeltaApply.m:177-207`: ```objc [archive enumerateItems:^(SPUDeltaArchiveItem *item, BOOL *stop) { NSString *relativePath = item.relativeFilePath; if ([relativePath.pathComponents containsObject:@".."]) { ...reject... } NSString *sourceFilePath = [source stringByAppendingPathComponent:relativePath]; NSString *destinationFilePath = [destination stringByAppendingPathComponent:relativePath]; { NSString *destinationParentDirectory = destinationFilePath.stringByDeletingLastPathComponent; NSDictionary *destinationParentDirectoryAttributes = [fileManager attributesOfItemAtPath:destinationParentDirectory error:NULL]; // It is OK for the directory parent to not exist if it has already been removed if (destinationParentDirectoryAttributes != nil) { NSString *fileType = destinationParentDirectoryAttributes[NSFileType]; if ([fileType isEqualToString:NSFileTypeSymbolicLink]) { ...reject... } } } ... }]; ``` Two gaps: 1. The check inspects only `destinationParentDirectory` (one level up), not all intermediate components. For a relative path `a/b/c.txt`, the kernel resolves through any symlink at component `a`. `attributesOfItemAtPath:` with the resolved path returns attributes of the resolved-through directory, which is `NSFileTypeDirectory` (not `NSFileTypeSymbolicLink`), so the check passes. 2. The check is skipped entirely if `destinationParentDirectoryAttributes == nil` (line 195). When the symlink target is to a directory that does not contain the named subpath, the parent appears not to exist and the check is skipped. The subsequent `fopen(path, "wb")` then creates the file along the resolved path. Write primitive For an item with `SPUDeltaItemCommandExtract` set, `SUBinaryDeltaApply.m:354-365` calls `[archive extractItem:item]` which goes through `SPUSparkleDeltaArchive.m:574-622` for regular files: ```objc [fileManager removeItemAtPath:itemFilePath error:NULL]; char itemFilePathString[PATH_MAX + 1] = {0}; if (![itemFilePath getFileSystemRepresentation:itemFilePathString maxLength:sizeof(itemFilePathString) - 1]) { ... } FILE *outputFile = fopen(itemFilePathString, "wb"); ``` `fopen(path, "wb")` follows symlinks at every path component and creates/truncates the file at the resolved path. If `/a` is a symlink to `/Library/LaunchDaemons` (for a root install) and the relative path is `a/com.attacker.plist`, the call writes `/Library/LaunchDaemons/com.attacker.plist`. The `chmod` follow-up at `SUBinaryDeltaApply.m:335` (`chmod(destinationFilePath.fileSystemRepresentation, sourceFileInfo.st_mode)`) and `SPUSparkleDeltaArchive.m:619` (`chmod(itemFilePathString, mode)`) likewise follows symlinks, so attacker-chosen permissions land on the attacker-chosen target. Threat model This primitive is reachable only when the archive can pass EdDSA signature verification, which requires either: • The developer's private signing key has been compromised, or • A separate vulnerability allows bypassing `SUSignatureVerifier` (none was identified in this review). Given a stolen private key, the attacker already has the ability to push a normal full-bundle update. The delta-apply traversal grants strictly more: arbitrary file write into directories outside ``. When the AppInstaller runs in the system domain (root), this becomes arbitrary file write as root, which is qualitatively broader than "replace the app bundle". It is therefore worth fixing as a defense-in-depth measure, even though the prerequisite (key compromise) is itself a worst case. PoC The PoC requires a valid EdDSA signature on the malicious `.delta` archive. With a test signing key under your control (any Sparkle test fixture key), generate a delta as follows: 1. Construct the archive payload with two items, in this order, using the `SPUSparkleDeltaArchive` writer (or by hand-assembling the format described in `SPUSparkleDeltaArchive.m` and `SPUDeltaArchiveProtocol.h`): ``` Item 1: relativeFilePath = "Contents/Resources/escape" commands = SPUDeltaItemCommandExtract (= 0x02) mode = S_IFLNK | 0o755 (= 0xA1ED) payload = "/Library/LaunchDaemons" Item 2: relativeFilePath = "Contents/Resources/escape/com.attacker.persistence.plist" commands = SPUDeltaItemCommandExtract (= 0x02) mode = S_IFREG | 0o644 (= 0x81A4) payload = ``` 2. Sign the archive with the test EdDSA key, publish it as a delta enclosure with matching `sparkle:edSignature`, and host it from a feed pointed at by a Sparkle host whose old-bundle public key matches. 3. Trigger a system-domain install. The flow: • `applyBinaryDelta` enumerates items. • Item 1 passes the `..` check (the path components are `Contents`, `Resources`, `escape` - no `..`). The parent `Contents/Resources` exists in the source-copy and is a directory, not a symlink. The check passes. `extractItem:` for `S_ISLNK(mode)` calls `createSymbolicLinkAtPath:withDestinationPath:` and creates `/Contents/Resources/escape -> /Library/LaunchDaemons`. • Item 2 passes the `..` check. Its parent `/Contents/Resources/escape` resolves through the just-created symlink to `/Library/LaunchDaemons`, whose attributes are returned as `NSFileTypeDirectory` (not symlink). The check passes. • `extractItem:` for `S_ISREG(mode)` does `removeItemAtPath` (no-op, target file does not yet exist) then `fopen("/Contents/Resources/escape/com.attacker.persis…