New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

1.13.1 on website has misleading version number #726

Closed
taoeffect opened this Issue Jan 31, 2016 · 12 comments

Comments

Projects
None yet
3 participants
@taoeffect

taoeffect commented Jan 31, 2016

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

This comment has been minimized.

taoeffect commented Jan 31, 2016

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

This comment has been minimized.

Member

zorgiepoo commented Jan 31, 2016

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

@taoeffect

This comment has been minimized.

taoeffect commented Jan 31, 2016

@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

This comment has been minimized.

Member

kornelski commented Jan 31, 2016

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

@kornelski kornelski closed this Jan 31, 2016

@kornelski

This comment has been minimized.

Member

kornelski commented Jan 31, 2016

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

This comment has been minimized.

taoeffect commented Jan 31, 2016

@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

This comment has been minimized.

Member

zorgiepoo commented Jan 31, 2016

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

This comment has been minimized.

taoeffect commented Jan 31, 2016

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

This comment has been minimized.

Member

kornelski commented Jan 31, 2016

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

This comment has been minimized.

taoeffect commented Jan 31, 2016

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

This comment has been minimized.

taoeffect commented Feb 1, 2016

@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

This comment has been minimized.

Member

kornelski commented Feb 1, 2016

@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.

@kornelski kornelski changed the title from 1.13.1 on website is still vulnerable! to 1.13.1 on website has misleading version number Feb 1, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment