1.13.1 on website has misleading version number

[taoeffect]

I downloaded this from the homepage: https://github.com/sparkle-project/Sparkle/releases/download/1.13.1/Sparkle-1.13.1.tar.bz2

Get Info reveals version: 1.13.1 git-2afc553

Commit 2afc553 is before the merged fixes took place in 0fe520f.

[taoeffect]

lol, and wtf the latest commit 03ca628 results in a .framework version of 1.13.0 git-03ca628 instead of 1.13.1 git-03ca628

[zorgiepoo]

Yeah, I couldn't reproduce the vulnerability with the latest release. I think the version label is just wrong...

[taoeffect]

@zorgiepoo It's unlikely that there'd be a mistake in the version. How are you trying to reproduce? I've been trying to reproduce as well with bettercap and failing when I know VLC is vulnerable, so just because you can't reproduce doesn't mean it's not vulnerable.

[kornelski]

Sorry for the confusion. I forgot to bump version number in master. It's not vulnerable, it was just showing old version number.

[kornelski]

You can run

fgrep 'about:blank' Sparkle.framework/Sparkle

on a copy of the framework to test whether the binary contains the fix. If it returns "Binary file … matches" it's safe.

[taoeffect]

@pornel I'm not entirely convinced. Even if you forgot to bump the minor version number in master, that doesn't change the fact that your automated build script stamped it with a commit that came before the fix.

What is the fgrep about? Why do you say that about:blank indicates the fix is there? (Which commit was it introduced in?)

[zorgiepoo]

How are you trying to reproduce? I've been trying to reproduce as well with bettercap and failing when I know VLC is vulnerable, so just because you can't reproduce doesn't mean it's not vulnerable.

I tested inserting the ftp:// and file:// URLs in an appcast that the blog post mentions, which worked on an older version of Sparkle but not on the latest one that was on the release page; I used the included test app.

What is the fgrep about? Why do you say that about:blank indicates the fix is there? (Which commit was it introduced in?)

70f6929

[taoeffect]

I have no idea what's going on.

70f6929 is also after 2afc553, and yet this 2afc553 build that I have has about:config inside of it. I searched the project and that string only seems to appear once.

So, no idea what's going on. Maybe the version stamping mechanism is broken @pornel?

[kornelski]

The string that was added was about:blank, not about:config. It's in the newly-added whitelist of valid URLs for the webview, so binaries that contain about:blank are the ones that have the fix.

The build with these fixes has been created a week before these commits were created. The commits were added later when we were ready to disclose the vulnerability. Please ignore the hash in the version tag.

[taoeffect]

The string that was added was about:blank, not about:config.

Oops, that was just a typo on my part.

The build with these fixes has been created a week before these commits were created. Please ignore what the version number says.

I see, so there must've been unstaged changes on top of 2afc553 when you created it?

[taoeffect]

@pornel Even if the version on the site is based on 70f6929, that's still not a complete fix as the memory exhaustion attack that's mentioned in the post is still possible. I believe that didn't get fixed until later in 0fe520f.

So could this issue be re-opened for that?

[kornelski]

@taoeffect You're mixing things up. The commit you've linked to is for local file disclosure via remote entities, and it is included in the binary.