I looked up the documentation for -[NSBundle bundleWithIdentifier:] just to be sure I knew how it works (and I didn't...):

The docs say it:

Returns the previously created NSBundle instance that has the specified bundle identifier

but also says:

However, if the initial lookup of an already loaded and cached bundle with the specified identifier fails, this method uses potentially time-consuming heuristics to attempt to locate the bundle.

Just going by these statements, if issue #571 occurred, this would mean that we can't trust the lookup, and it would dive into the updated app's bundle we created a NSBundle instance out of..? If so, that's very strange, and I can't reproduce that myself having written some small test code. If this is the cause of the issue, this could potentially affect Autoupdate.app too.

An attacker could also in theory make their "updated app" using Sparkle's bundle ID, but I don't think that's what happened in that issue.

Perhaps a more realistic scenario is that the host app creates a NSBundle instance from a Sparkle.framework lying elsewhere on their machine. If that happens, can we trust using [NSBundle bundleWithIdentifier:SUBundleIdentifier] at all from the host app?

On my machine, inside of Autoupdate.app, [NSBundle bundleWithIdentifier:SUBundleIdentifier] just evaluates to nil and uses the main bundle. Thus implying that string files at least have to be inside of Autoupdate.app

IIRC Autoupdate.app runs after the new bundle has been verified, so untrusted isn't a problem.

Technically speaking, the last bit of "trust" code is here in Autoupdate's SUPlainInstaller where it checks for a downgrade attack. But one could argue that code should be moved right next to the other validation code.

In any case, we wouldn't want to use string files from a different version of Sparkle, even if they're trusted (string keys may not match, etc).

Uh oh!

Updater.app has copy of Sparkle.strings files #577

Description

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions