Handbrake: Code Signing on MacOS X

[ajmas]

It would be useful to have Handbrake code signed on MacOS X. This is especially true for less 'techie' users, so they don't need to have to understand how to allow it to run.

[bradleysepos]

This has been discussed and we don't disagree. However, there are some barriers for us as a project given Apple's requirements for an organization to secure a Developer ID and the associated signing abilities. Need a legal entity with a DUNS number, and independent verification to start. It is far easier to approach this from an individual perspective, but in any case it's non-trivial for the time being.

Marking as an enhancement since we hope to resolve this eventually.

[Boggartfly]

@bradleysepos So handbrake does not have a legal entity associated with it?

[sr55]

No. HandBrake is a hobby built by folks in their free time.

[sr55]

Same applies to a large portion of small to medium open source projects. A lot, like us, are also completely unfunded.

[Boggartfly]

@sr55 Yeah, I feel the pain man. I bet there might be someone out there willing to sponsor Handbrake considering the amount of value that it brings to people.
For example if Handbrake had a video encoding network service(either on site or in the cloud), that would be something that people would pay for.

[Boggartfly]

That way the hypothetical org can support itself, while still maintaining the codebase(Like a non-profit).

[bdkjones]

Why not just find an Apple Developer who can sign the binary for an official release? For example, I'd be happy to sign Handbrake with my developer account.

Code Signing, while annoying, is definitely a net-win for everyone and you guys should not be shipping an unsigned app in 2017.

[Boggartfly]

Legal issues. Who owns Handbrake? The person who would be in charge of the
developer account should be invested in the project. An organization
account makes sense. How can we help? I guess there needs to be a legal
entity so that it can apply for a account. Also who pays for it? Lot of
questions with no or difficult answers.
Guys who is the lead developer of Handbrake? Maybe he can shed some light
on this matter! Can someone tag him here?

On Sun, Apr 16, 2017, 9:13 PM Bryan Jones [e-mail] wrote:

Why not just find an Apple Developer who can sign the binary for an
official release? For example, I'd be happy to sign Handbrake with my
developer account.

Code Signing, while annoying, is definitely a net-win for everyone and you
guys should not be shipping an unsigned app in 2017.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/HandBrake/HandBrake/issues/619#issuecomment-294358311,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABoJFx2E_mOxCGsoXCewY-AL7FxPkOaLks5rwjcrgaJpZM4MXk2E
.

[bdkjones]

Mmm, I don't think it's unreasonable to have a single appointed person to build the release for macOS and then sign it with their account. That person need not "own" Handbrake; they're just the designated responsible party for building and signing the releases.

I agree that the ideal solution is to have a legal entity that owns Handbrake and has its own developer account. But it sounds like that's not really an option here?

[Boggartfly]

People don't really know who are the stakeholders. You'd need a lawyer to
process all the legalese.

On Sun, Apr 16, 2017, 9:41 PM Bryan Jones [e-mail] wrote:

Mmm, I don't think it's unreasonable to have a single appointed person to
build the release for macOS and then sign it with their account. That
person need not "own" Handbrake; they're just the designated responsible
party for building and signing the releases.

I agree that the ideal solution is to have a legal entity that owns
Handbrake and has its own developer account. But it sounds like that's not
really an option here?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/HandBrake/HandBrake/issues/619#issuecomment-294359792,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABoJFzSQ4w-u0RKIhwsLzwsCMbc-gpzxks5rwj2egaJpZM4MXk2E
.

[sr55]

It's not owned by 1 person. It's managed by 3 developers. (3 King principals) Any one developer moves on and we try swap another trust worthy individual in. 2 out of 3 developers need to agree to move forward with something and so on.

Having this bound to a single developer is a single point of failure. We all have busy lives and don't always have time to contribute to HandBrake. So, if said developer who had an individual cert wasn't around it could block a release for a significant amount of time. Also means we are stuck doing manual builds.

I agree that the ideal solution is to have a legal entity that owns Handbrake and has its own developer account. But it sounds like that's not really an option here?

It's expensive thing to do. Project policy is to not accept donations as that's another can of worms.

I should point out that we also have Windows to account for as well and certs for that are quite pricey and very hard to get if your not an Org. So far the 3 authorities i've spoken with would require me to visit them with ID for verification, which would involve a pricey flight. It's actually cheaper to setup an organisation which I'd probably not have change from £500 a year for.

[Boggartfly]

Hmm. I want to help Scott. How can I do that?
I have an iOS dev account.

On Sun, Apr 16, 2017, 9:50 PM Scott [e-mail] wrote:

It's not owned by 1 person. It's managed by 3 developers. (3 King
principals) Any one developer moves on and we try swap another trust worthy
individual in. 2 out of 3 developers need to agree to move forward with
something and so on.

Having this bound to a single developer is a single point of failure. We
all have busy lives and don't always have time to contribute to HandBrake.
So, if said developer who had an individual cert wasn't around it could
block a release for a significant amount of time. Also means we are stuck
doing manual builds.

I agree that the ideal solution is to have a legal entity that owns
Handbrake and has its own developer account. But it sounds like that's not
really an option here?

It's expensive thing to do. Project policy is to not accept donations as
that's another can of worms.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/HandBrake/HandBrake/issues/619#issuecomment-294360263,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABoJF4--MZCWryxB-Af7FOgkzoL0i9pLks5rwj_CgaJpZM4MXk2E
.

[ajmas]

Based on the current situation, on the Mac side, maybe we could go with the following approach:

• Have developerX sign the application
• Have a page on the handbrake site indicating who the signing entity is for each version. This acts as a reference for anyone needing to check, in case of doubt.
• If developerX is no longer able to sign, then
  
  
  
  • Establish new signing person
  
  
  • Create new release using the new person's certificate
  
  
  • Ensure the signing history page is updated
  
  

developerX, ideally being a trusted developer part of the inner circle of developers.

I would imagine that whenever there is a change of the 'inner circle', it needs the other developers to approve and therefore establish a chain of trust?

The automated build process should probably include some sort of audit log of which certificate which was used for each build? The signing could probably be also be limited to the release branch?

BTW Circle CI has this on Code Signing for iOS (possibly suitable for macOS): https://circleci.com/docs/1.0/ios-code-signing/

[bdkjones]

I agree with this approach, but I might modify it slightly:

1. Have a "pool" of developers who are authorized to build and sign releases. This pool could be two or three developers who are involved in core development or who are vetted by the core developers.

2. Having this "pool" available solves the problem of what happens when you want to release a version but the usual signing developer is unavailable.

3. Because you're not releasing on the App Store, the signing developer does not need to be consistent across releases; each release need merely be signed by an active developer to be GateKeeper-compliant. (Not sure about the legal end of this; I haven't read the full developer agreement in a while. But GateKeeper itself has no problem with changing certificates, as long as each is valid.)

4. Under all circumstances, it's CRITICAL that the actual build is done by the developer signing the application. You can't just send that developer a pre-built binary and have them sign it. That breaks trust because the signing developer can't vouch that the built binary does not contain malicious code. Signed release builds MUST be manually done by the signing developer on their own Mac.

[galad87]

Does Sparkle and sandboxing works if you change the certificate?

[bdkjones]

Sparkle should work just fine if you sign the update with a DSA signature and put that in the XML file for Sparkle. Sparkle comes with a couple command line scripts to do that. I've used this before to update an app where I've changed the bundle identifier across major versions.

Sandboxing is a good question. I didn't realize Handbrake was sandboxed (it doesn't have to be because it's not in the App Store).

[galad87]

It's not right now, because we needs code signing to enable it. HandBrake uses a lot of libraries, each one with its own share of security issues, sandbox is not perfect, but it will be better than nothing.

[Boggartfly]

So how can I help? Like I said I have a developer account.

On Sun, Apr 16, 2017, 11:12 PM Damiano Galassi [e-mail]
wrote:

It's not right now, because we needs code signing to enable it. HandBrake
uses a lot of libraries, each one with its own share of security issues,
sandbox is not perfect, but it will be better than nothing.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/HandBrake/HandBrake/issues/619#issuecomment-294364281,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABoJF9lZuKpuQKx-pFNp0GRnGc8TPIMxks5rwlLygaJpZM4MXk2E
.

[sr55]

There isn't much you can do to help I'm afraid. For now, this is a problem we the core developers need to figure out. As bdkjones alluded to above, the developer that has the keys, has to do the build to maintain trust. This also restricts it to known key individuals.

If/when we figure out how we are going to deal with this, I'll update this thread.

[bdkjones]

I'd say it should be a "when" and not an "if", especially since the writing is sort of on the wall: the option to allow unsigned apps is missing from Security in macOS 10.12. It has to be enabled with a terminal command. It's only a matter of time until unsigned apps are flat-out forbidden.

This should be solved; the can should not simply be kicked down the road.

Sent from my iPhone

On Apr 16, 2017, at 13:00, Scott [e-mail] wrote:

There isn't much you can do to help I'm afraid. For now, this is a problem we the core developers need to figure out. As bdkjones alluded to above, the developer that has the keys, has to do the build to maintain trust. This also restricts it to known key individuals.

If/when we figure out how we are going to deal with this, I'll update this thread.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[Boggartfly]

So what do you want to do Bryan? I wanted to help. I was wondering how!

On Mon, Apr 17, 2017, 1:06 AM Bryan Jones [e-mail] wrote:

I'd say it should be a "when" and not an "if", especially since the
writing is sort of on the wall: the option to allow unsigned apps is
missing from Security in macOS 10.12. It has to be enabled with a terminal
command. It's only a matter of time until unsigned apps are flat-out
forbidden.

This should be solved; the can should not simply be kicked down the road.

Sent from my iPhone

On Apr 16, 2017, at 13:00, Scott [e-mail] wrote:

There isn't much you can do to help I'm afraid. For now, this is a
problem we the core developers need to figure out. As bdkjones alluded to
above, the developer that has the keys, has to do the build to maintain
trust. This also restricts it to known key individuals.

If/when we figure out how we are going to deal with this, I'll update
this thread.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/HandBrake/HandBrake/issues/619#issuecomment-294369850,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABoJF6l17-1QbbqchAG-Y6lTIV9TNThUks5rwm21gaJpZM4MXk2E
.

[ajmas]

BTW It may be worth contacting the people over at VideoLAN and seeing how they were able to establish themselves, since I see VLC for iOS is associated with "VideoLAN and authors".

One other thing that should be considered is the transferring the ownership of an app:

https://developer.apple.com/library/content/documentation/LanguagesUtilities/Conceptual/iTunesConnect_Guide/Chapters/TransferringAndDeletingApps.html

Also we should consider the situation if the release manager ever goes rogue, due to a falling out - it happens.

[jstebbins]

VideoLAN is a legal entity. https://www.videolan.org/videolan/

They raise money and apply it to such things. The have official meetings of the board where minutes are recorded as required by law, etc, etc. The overhead of creating and maintaining such a legal entity makes it a non-starter for us.

[bdkjones]

Well, given today's news that your server got hacked and a malicious binary was made available, I think it would be wise to escalate this issue. This sort of thing is exactly what code-signing is designed to thwart. The hacker would have needed to sign the alternate binary with a certificate that could have been revoked easily, which makes the attack harder to execute and greatly limits the potential damage from it.

Handbrake is currently a terrible citizen on macOS because not only are you failing to adopt basic security measures, you're also actively training users to disregard the warnings about running unsigned software. You walk people through the steps needed to bypass gatekeeper, which is a huge disservice to folks who don't have the technical knowledge to know when that's okay and when it's not.

I love Handbrake. But the bottom line is that you guys need to shape up. Today's hack should be the wake up call you needed to get your butts in gear and stop ignoring security.

Sent from my iPhone

On Apr 18, 2017, at 09:40, John Stebbins [e-mail] wrote:

VideoLAN is a legal entity. https://www.videolan.org/videolan/

They raise money and apply it to such things. The have official meetings of the board where minutes are recorded as required by law, etc, etc. The overhead of creating and maintaining such a legal entity makes it a non-starter for us.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[johnypony3]

i understand the legalese issue, it does sound like its more molehill rather than a mountain, but hey its just my opinion.

what im mighty confused about are the following:

1. why are you serving the artifacts from the main site? i see releases on github, yet even this formulae is pointed to your domain. it would be much more complex to thwart 2fa.
2. where is the build? travis.ci and appveyor would cover all of your build cases. the hashes would be verifiable, since you can output a file and have it be an artifact of the build. and the whole thing can be ran via a tag/commit/merge on the repo. these build servers can sign the artifacts, so in no way would you be blocked.

your entire site can actually be hosted on github.

is the github repo owned by all 3 of you? im guessing the answer is no. as such you already appointed the owner of the software.

[sr55]

We are not arguing against code signing. It's something we want to do but the requirements that we have to meet to get the cert pose a lot of not easy to solve problems for us, some of which have a very high cost or legal / contractual implications (not just $99 a year for a cert)

This sort of thing is exactly what code-signing is designed to thwart. The hacker would have needed to sign the alternate binary with a certificate that could have been revoked easily, which makes the attack harder to execute and greatly limits the potential damage from it.

I'd point out that you need to notice a problem in order to revoke a certificate. That leaves you with a window of opportunity which in this case was far too long. We are already working on better monitoring solutions for the site to reduce the window for any potential future issues. We flat out failed here. This was something we were working on in the background but hadn't got over the line yet.

@johnypony3 -> I do not believe GitHub would be too happy with the kind of bandwidth we use. It's not uncommon for us to hit 6TB a month. Sometimes higher during a release month. We moved away from SF.net because of their reputation and various other options we've looked at are either not much better or don't have a good security track record or cost money we simply don't have.

Update: Discounting downloads completely, our site is still nearly double the 100GB soft limit on a quiet month.

I'd also like to state that we take security very seriously. I've already stated a number of points https://github.com/HandBrake/HandBrake/issues/725#issuecomment-299704177

One of those points is relying on trustworthy 3rd party services like GitHub where possible.

Finally, HandBrake is not owned by 1 person. There are 3 leads in 3 different countries. Even then, where 1 stops contributing, they are replaced. The idea being that it helps the project live on and not die off as many OS projects do. None of us are original.

[bradleysepos]

@bdkjones I certainly understand your frustration. You have our apologies, for what it's worth.

We are not socially engineering people into lowering their security. Our documentation links to the same guidelines Apple provides. It's not ideal, but we explain what is happening and why. It's also important to recognize that a while a certificate would positively change the application launch process, it is not a complete security solution. Thankfully, Apple's XProtect should now be silently protecting macOS users from the specific threat without additional interaction.

Gatekeeper is a fine addition to macOS. We want to make it happen for many reasons. It will not solve all potential security issues. We continue to review and implement reasonable measures across the entire attack surface. Scott and I mentioned a few improvements we're making on #725. Gatekeeper will be a welcome addition once we can work out the logistics.

is the github repo owned by all 3 of you? im guessing the answer is no. as such you already appointed the owner of the software.

The answer is yes. GitHub makes it easy to set up an organization with members and member credentials!

[bradleysepos]

what im mighty confused about are the following:

1. why are you serving the artifacts from the main site? i see releases on github, yet even this formulae is pointed to your domain. it would be much more complex to thwart 2fa.
2. where is the build? travis.ci and appveyor would cover all of your build cases. the hashes would be verifiable, since you can output a file and have it be an artifact of the build. and the whole thing can be ran via a tag/commit/merge on the repo. these build servers can sign the artifacts, so in no way would you be blocked.

@johnypony3 We are using Jenkins, which is automated similarly.

Your point about two-factor is well taken. That said, two-factor does not necessarily require a third party. We have reasonable authentication mechanisms in place.

Authentication does not negate the possibility of a breach due to a known or unknown software vulnerability. We're adding additional on-the-fly validation to our architecture to protect against serving unrecognized binaries and improving our alert notifications to reduce the time needed to respond.

[Boggartfly]

As evidenced by some very unfortunate news Handbrake got pwned. I really don't understand why you guys don't try to get everyone in a place, saying look we need to get this fixed. In order to get a legal structure for Handbrake it costs money. So why not create / modify project policy to get donations with a special terms and conditions agreement?(Since you may be worried about donors driving project direction) I could ask my lawyer uncle to help you guys with this!
Considering the amount of traffic that you are handling it seems likely that you guys would get enough starter costs!

[jbkempf]

VideoLAN (I'm the president), is a legal entity done to help open source multimedia projects.
We are an open-source project and a non-profit organization.

We host numerous open source projects that are not VLC, like x264 or DVBlast.
We host FFmpeg git and we host some builders for libav-fate.

We maintain libdvdread, libdvdnav, libdvdcss, libbluray and other libraries used by handbrake...

We provide git, gitlab, ftp, dns, mailing lists, and buildbots. And a big mirroring system.

We have a valid codesign certificate for Apple systems, a valid Authenticode for Windows, and a registered Android account. We GPG sign every source and binary too.

We can even have a one-time-docker on our jenkins to build handbrake releases (and avoid any issue) for Windows and macOS.

So, I believe we can help with this issue. Please contact us :)

[Boggartfly]

@jbkempf Thank you! Finally someone with experience! @sr55 @bdkjones

[bradleysepos]

Thanks J-B. We're very grateful for the working relationship we have with VideoLAN. Perhaps we can do more!

@Boggartfly Nice one.

[bradleysepos]

We recently published a postmortem on the recent security breach here: https://forum.handbrake.fr/viewtopic.php?f=33&t=36399

[bradleysepos]

There seems to be some confusion regarding signing the HandBrake application with an Apple Developer ID, and what benefits doing so offers. Some observations on this point that may help:

While signing the application would allow someone to launch a new install of HandBrake without making a macOS Gatekeeper exception, this does not preclude anyone from launching an unsigned, maliciously crafted application with the same name and icon, such as the one distributed briefly during the security breach on our server.

The dialogs presented (or not) by macOS when launching signed or unsigned apps differ, so the social engineering necessary to trick a user into running the malware is slightly different. Unfortunately, the technical attack in this case is unchanged. Code signing alone would not have prevented this attack on a technical level, but a difference in the application launch process may have tipped off an astute user that something wasn't right. That said, it seems more than a few people were successfully phished by a fake system password request, which is unfortunate. We of course take this very seriously, and you can read more about our response in the postmortem.

It is also important to note that revoking a signing certificate is only useful in the case where a developer has signed a malware infected application, which of course we did not. If HandBrake was signed on macOS, revoking the signature would do nothing to thwart an unsigned, malicious version.

On the other hand, HandBrake's automatic update functionality (powered by the Sparkle update framework), uses cryptography to validate any update files it downloads, which in this case prevented thousands of potential infections. So we are using cryptography to our users' benefit there.

Apple's XProtect software has been updated to detect and prevent infection of OSX/Proton.B automatically. XProtect uses definitions to identify malware much like popular commercial antivirus products, and does not need cryptography to be effective. Provided a user has "Install system data files and security updates" enabled on the App Store preference pane in System Preferences, no further interaction should be necessary to prevent new infections of OSX/Proton.B at this point.

Signed applications are a great thing, but XProtect is ultimately the most effective protection cases like this one.

Regarding barriers to code signing on macOS, it's not just the $99 yearly fee for a signing cert; I'd gladly pay it myself if that was the only issue. In fact, the biggest issue is that Apple's extended validation methods do not easily accommodate 5 developers in 5 countries without a verifiable legal entity. And naturally, it would be irresponsible for us to let just anyone sign our application. The entire point of code signing is trust and the ability to revoke trust.

That said, code signing is quite important to us, and it's something we've been working on for over a year now. Code signing isn't simply a switch to be flipped on; rather, it needs to be implemented safely and securely in order to be trustworthy. Hopefully we can add this additional layer of assurance to HandBrake soon.

[bdkjones]

Thanks for the postmortem. Exactly how, though, were your servers compromised? Did someone's SSH key leak? Did you not disable password-based login to the server and rely only on SSH keys? Was there an extra service running with an exposed port that provided an attack vector? I'm curious as someone who runs and administers a server that distributes software---the details of how yours were compromised would help others not fall prey to the same traps.

Sent from my iPhone

On May 16, 2017, at 09:14, Bradley Sepos [e-mail] wrote:

There seems to be some confusion regarding signing the HandBrake application with an Apple Developer ID, and what benefits doing so offers. Some observations on this point that may help:

While signing the application would allow someone to launch a new install of HandBrake without making a macOS Gatekeeper exception, this does not preclude anyone from launching an unsigned, maliciously crafted application with the same name and icon, such as the one distributed briefly during the security breach on our server.

The dialogs presented (or not) by macOS when launching signed or unsigned apps differ, so the social engineering necessary to trick a user into running the malware is slightly different. Unfortunately, the technical attack in this case is unchanged. Code signing alone would not have prevented this attack on a technical level, but a difference in the application launch process may have tipped off an astute user that something wasn't right. That said, it seems more than a few people were successfully phished by a fake system password request, which is unfortunate. We of course take this very seriously, and you can read more about our response in the postmortem.

It is also important to note that revoking a signing certificate is only useful in the case where a developer has signed a malware infected application, which of course we did not. If HandBrake was signed on macOS, revoking the signature would do nothing to thwart an unsigned, malicious version.

On the other hand, HandBrake's automatic update functionality (powered by the Sparkle update framework), uses cryptography to validate any update files it downloads, which in this case prevented thousands of potential infections. So we are using cryptography to our users' benefit there.

Apple's XProtect software has been updated to detect and prevent infection of OSX/Proton.B automatically. XProtect uses definitions to identify malware much like popular commercial antivirus products, and does not need cryptography to be effective. Provided a user has "Install system data files and security updates" enabled on the App Store preference pane in System Preferences, no further interaction should be necessary to prevent new infections of OSX/Proton.B at this point.

Signed applications are a great thing, but XProtect is ultimately the most effective protection cases like this one.

Regarding barriers to code signing on macOS, it's not just the $99 yearly fee for a signing cert; I'd gladly pay it myself if that was the only issue. In fact, the biggest issue is that Apple's extended validation methods do not easily accommodate 5 developers in 5 countries without a verifiable legal entity. And naturally, it would be irresponsible for us to let just anyone sign our application. The entire point of code signing is trust and the ability to revoke trust.

That said, code signing is quite important to us, and it's something we've been working on for over a year now. Code signing isn't simply a switch to be flipped on; rather, it needs to be implemented safely and securely in order to be trustworthy. Hopefully we can add this additional layer of assurance to HandBrake soon.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[Boggartfly]

Good idea. Share your story so that others may avoid the same mistakes.
Thanks.

On Wed 17 May, 2017, 12:17 AM Bryan Jones, [e-mail] wrote:

Thanks for the postmortem. Exactly how, though, were your servers
compromised? Did someone's SSH key leak? Did you not disable password-based
login to the server and rely only on SSH keys? Was there an extra service
running with an exposed port that provided an attack vector? I'm curious as
someone who runs and administers a server that distributes software---the
details of how yours were compromised would help others not fall prey to
the same traps.

Sent from my iPhone

On May 16, 2017, at 09:14, Bradley Sepos [e-mail]
wrote:

There seems to be some confusion regarding signing the HandBrake
application with an Apple Developer ID, and what benefits doing so offers.
Some observations on this point that may help:

While signing the application would allow someone to launch a new
install of HandBrake without making a macOS Gatekeeper exception, this does
not preclude anyone from launching an unsigned, maliciously crafted
application with the same name and icon, such as the one distributed
briefly during the security breach on our server.

The dialogs presented (or not) by macOS when launching signed or
unsigned apps differ, so the social engineering necessary to trick a user
into running the malware is slightly different. Unfortunately, the
technical attack in this case is unchanged. Code signing alone would not
have prevented this attack on a technical level, but a difference in the
application launch process may have tipped off an astute user that
something wasn't right. That said, it seems more than a few people were
successfully phished by a fake system password request, which is
unfortunate. We of course take this very seriously, and you can read more
about our response in the postmortem.

It is also important to note that revoking a signing certificate is only
useful in the case where a developer has signed a malware infected
application, which of course we did not. If HandBrake was signed on macOS,
revoking the signature would do nothing to thwart an unsigned, malicious
version.

On the other hand, HandBrake's automatic update functionality (powered
by the Sparkle update framework), uses cryptography to validate any update
files it downloads, which in this case prevented thousands of potential
infections. So we are using cryptography to our users' benefit there.

Apple's XProtect software has been updated to detect and prevent
infection of OSX/Proton.B automatically. XProtect uses definitions to
identify malware much like popular commercial antivirus products, and does
not need cryptography to be effective. Provided a user has "Install system
data files and security updates" enabled on the App Store preference pane
in System Preferences, no further interaction should be necessary to
prevent new infections of OSX/Proton.B at this point.

Signed applications are a great thing, but XProtect is ultimately the
most effective protection cases like this one.

Regarding barriers to code signing on macOS, it's not just the $99
yearly fee for a signing cert; I'd gladly pay it myself if that was the
only issue. In fact, the biggest issue is that Apple's extended validation
methods do not easily accommodate 5 developers in 5 countries without a
verifiable legal entity. And naturally, it would be irresponsible for us to
let just anyone sign our application. The entire point of code signing is
trust and the ability to revoke trust.

That said, code signing is quite important to us, and it's something
we've been working on for over a year now. Code signing isn't simply a
switch to be flipped on; rather, it needs to be implemented safely and
securely in order to be trustworthy. Hopefully we can add this additional
layer of assurance to HandBrake soon.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/HandBrake/HandBrake/issues/619#issuecomment-301878007,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABoJF2ARy03HCQSCpjPMAU6jv8ps1RGDks5r6e8tgaJpZM4MXk2E
.

[bdkjones]

This analysis of code-signing is a little off. While I agree that it would not have stopped this attack, it MAY have mitigated some of the infections. That's because, right now, when I run the legitimate Handbrake download, I see the prompt to bypass GateKeeper and I think, "Oh, that's right. Handbrake doesn't do code signing. This is normal." Had you guys BEEN using code signing, my reaction to that prompt would have been, "Wait a minute...this isn't normal. Why is it asking me to bypass Gatekeeper?" And I'd have done some investigation.

If the person who uploaded the malicious binary had been required to sign it with a valid certificate (to avoid suspicion in a world where Handbrake is usually signed), then we would have had the identity of the perpetrator and Apple could have instantly flipped the switch off to forbid that maliciously-signed binary from running.

Bottom line: by not signing the app, users are trained to ignore alarm bells that they should NOT ignore. That's the issue.

Sent from my iPhone

On May 16, 2017, at 09:14, Bradley Sepos [e-mail] wrote:

There seems to be some confusion regarding signing the HandBrake application with an Apple Developer ID, and what benefits doing so offers. Some observations on this point that may help:

While signing the application would allow someone to launch a new install of HandBrake without making a macOS Gatekeeper exception, this does not preclude anyone from launching an unsigned, maliciously crafted application with the same name and icon, such as the one distributed briefly during the security breach on our server.

The dialogs presented (or not) by macOS when launching signed or unsigned apps differ, so the social engineering necessary to trick a user into running the malware is slightly different. Unfortunately, the technical attack in this case is unchanged. Code signing alone would not have prevented this attack on a technical level, but a difference in the application launch process may have tipped off an astute user that something wasn't right. That said, it seems more than a few people were successfully phished by a fake system password request, which is unfortunate. We of course take this very seriously, and you can read more about our response in the postmortem.

It is also important to note that revoking a signing certificate is only useful in the case where a developer has signed a malware infected application, which of course we did not. If HandBrake was signed on macOS, revoking the signature would do nothing to thwart an unsigned, malicious version.

On the other hand, HandBrake's automatic update functionality (powered by the Sparkle update framework), uses cryptography to validate any update files it downloads, which in this case prevented thousands of potential infections. So we are using cryptography to our users' benefit there.

Apple's XProtect software has been updated to detect and prevent infection of OSX/Proton.B automatically. XProtect uses definitions to identify malware much like popular commercial antivirus products, and does not need cryptography to be effective. Provided a user has "Install system data files and security updates" enabled on the App Store preference pane in System Preferences, no further interaction should be necessary to prevent new infections of OSX/Proton.B at this point.

Signed applications are a great thing, but XProtect is ultimately the most effective protection cases like this one.

Regarding barriers to code signing on macOS, it's not just the $99 yearly fee for a signing cert; I'd gladly pay it myself if that was the only issue. In fact, the biggest issue is that Apple's extended validation methods do not easily accommodate 5 developers in 5 countries without a verifiable legal entity. And naturally, it would be irresponsible for us to let just anyone sign our application. The entire point of code signing is trust and the ability to revoke trust.

That said, code signing is quite important to us, and it's something we've been working on for over a year now. Code signing isn't simply a switch to be flipped on; rather, it needs to be implemented safely and securely in order to be trustworthy. Hopefully we can add this additional layer of assurance to HandBrake soon.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[bradleysepos]

None of our personal machines or credentials were compromised, from what we can tell. Of course we changed all passwords and keys as a precaution. I believe we were using passwords in addition to SSH keys, but don't quote me on that.

The compromised machine primarily served download files over https. We also stored some backup data there (nothing critical). For a time, we used it as a Jenkins agent, which would have opened an additional port when active.

Without going too deep into our technical analysis of the machine, it seems a software vulnerability was used to gain access. This was a sophisticated and well-financed attack. Proton is relatively expensive malware and it would not surprise me to learn the attacker purchased other malicious code to take advantage of fully patched Linux.

I do not disagree with your assessment on the social aspects of code signing. This is a major reason why we've been pursuing it for over a year. Even from a convenience level, it will be a welcome addition once implemented.

[Boggartfly]

Consider contacting videolan. They've even offered to help!

On Wed 17 May, 2017, 12:28 AM Bradley Sepos, [e-mail]
wrote:

None of our personal machines or credentials were compromised, from what
we can tell. Of course we changed all passwords and keys as a precaution. I
believe we were using passwords in addition to SSH keys, but don't quote me
on that.

The compromised machine primarily served download files over https. We
also stored some backup data there (nothing critical). For a time, we used
it as a Jenkins agent, which would have opened an additional port when
active.

Without going too deep into our technical analysis of the machine, it
seems a software vulnerability was used to gain access. This was a
sophisticated and well-financed attack. Proton is relatively expensive
malware and it would not surprise me to learn the attacker purchased other
malicious code to take advantage of fully patched Linux.

I do not disagree with your assessment on the social aspects of code
signing. This is a major reason why we've been pursuing it for over a year.
Even from a convenience level, it will be a welcome addition once
implemented.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/HandBrake/HandBrake/issues/619#issuecomment-301881006,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABoJF9roPRXWEKLud-3yzjOpSaxDRRVbks5r6fHMgaJpZM4MXk2E
.

[bradleysepos]

I should add, I've had this conversation a few times recently and I'm surprised some people (not necessarily yourselves) find it hard to believe that brand new variant of a relatively new, advanced, and expensive malware would be accompanied by a 0-day server exploit.

[bradleysepos]

@Boggartfly Indeed, we internally discussed the possibility of teaming up with VideoLAN on code signing and other matters long before this incident. Some of us know VideoLAN people personally and attend VDD in Europe every year. Suffice to say, we're grateful for the help they've extended to us both publicly and privately. I have no further information on the subject at this time.

[bdkjones]

Oh, I don't find it hard to believe there's an exploit that would compromise a fully-patched Linux box. There's bugs in every system, even the most hardened Linux server. In some ways, that's actually comforting because it means I'm not doing anything monumentally stupid that puts my users at risk. There's nothing I can do against zero-day exploits nobody knows about.

Sent from my iPhone

On May 16, 2017, at 12:01, Bradley Sepos [e-mail] wrote:

I should add, I've had this conversation a few times recently and I'm surprised some people (not necessarily yourselves) find it hard to believe that brand new variant of a relatively new, advanced, and expensive malware would be accompanied by a 0-day server exploit.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[bradleysepos]

There's nothing I can do against zero-day exploits nobody knows about.

Absolutely. This is why we had been working on an assets monitoring and emergency notifications solution in the months preceding the attack. Unfortunately, we hadn't fully implemented it at the time of the attack, but now it's in place and we should be able to recognize such threats more quickly.

[sr55]

There's nothing I can do against zero-day exploits nobody knows about.

The best mitigation for this is container isolation of all services. It's a bit of a pain when maintaining a site, but if for example, one service gets compromised (i.e a blog, forum, build server etc), it limits what the attacker can do if each service runs in it's own container. I.e if your download server gets hijacked, the attacked can't also easily (hopefully) hijack the appcasts for the apps sparkle updater.

[bdkjones]

Panic got hit by this incident and this excerpt is extremely relevant. From https://panic.com/blog/stolen-source-code/

"I also likely bypassed the Gatekeeper warning without even thinking about it, because I run a handful of apps that are still not signed by their developers. And that was that, my Mac was completely, entirely compromised in 3 seconds or less."

Sent from my iPhone

On May 16, 2017, at 13:28, Scott [e-mail] wrote:

There's nothing I can do against zero-day exploits nobody knows about.

The best mitigation for this is container isolation of all services. It's a bit of a pain when maintaining a site, but if for example, one service gets compromised (i.e a blog, forum, build server etc), it limits what the attacker can do if each service runs in it's own container.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[bradleysepos]

Indeed. We became aware of this earlier today. Very upsetting, to say the least. This certainly reinforces the point about social engineering we've both alluded to (directly and indirectly).

Another observation from the article: the day Sierra came out, it broke our users' ability to securely update the HandBrake app using Sparkle. Had Steven been able to use the automatic update functionality, it would have failed the crypto check.

I mention this not to point blame at Apple or Sparkle, but to illustrate how one technical issue can domino into other issues, potentially posing barriers to security (or ease there of).

Edit: s/Cabel/Steven/

[jstebbins]

I'm inclined to think that this poor individual would have been pwned just the same if we had an apple ID.

The attacker would most likely have posted an infected file that is not signed. The older version of HandBrake Steven was updating was not signed so he had no expectation that the new version would be signed. And in fact, as he said, he is accustomed to several apps he uses on a regular basis being unsigned. He would have clicked through just the same because he is accustomed to doing so for HandBrake and other unsigned apps.

This is of coarse just one example. I'm sure there are people out there that would think twice under these hypothetical circumstances. But then, people should have given things a second thought when asked for admin password under the real circumstances that did occur.

[jbkempf]

@sr55 VideoLAN new servers have isolation of all services, notably FTP, WWW, Git, gitlab, trac+forum+wiki, DB are all in different LXC. Exactly for those reasons.
And developers have almost no access to those machines. FTP managers just manage the FTP, etc...

[bradleysepos]

@jbkempf Good to know. HandBrake's services also use container isolation, for what it's worth.

[jbkempf]

@bradleysepos to get a correct certificate from Apple being a French non-profit took a lot of time, so I really feel your pain... But now, we can share the signing+certificates with more people...

[bradleysepos]

@jbkempf Yes, absolutely. Hopefully we can make this happen soon.

Indeed, the perception seems to be that getting a certificate from Apple just takes $99 and an email address. If only that were the case...

[bdkjones]

Bradley, it's not as if code-signing came out six months ago and you guys have been figuring out how to adopt it. This stuff has been around and common for YEARS. You've had YEARS to figure out the entity complexities. In fact, gatekeeper has been around so long that the option to allow unsigned apps is now gone from system preferences!

Gatekeeper is excellent low-hanging-fruit for security and you guys have been lax on adopting it for a long, long time. What bothers me most is that Handbrake is trying to rationalize how NOT signing wouldn't have solved the problem and isn't really a fix-all, etc. I don't see you guys taking responsibility and saying, "Yea, we should have been on top of this a long time ago. We dragged our feet. That's on us." The community is forgiving and tends to look favorably on responses like that. They tend to reject excuses for why you're not using every available security measure to protect your users.

And I disagree with the idea that Steven would have fallen prey anyway. If, say, Transmission told me it couldn't run because it wasn't signed, the speed at which I would trash that download would break the goddamn laws of physics. But you've now spent YEARS training your users that Handbrake isn't signed and they have to ignore alarm bells. It will take a long time to undo that training and damage.

Sent from my iPhone

On May 17, 2017, at 13:59, Bradley Sepos [e-mail] wrote:

@jbkempf Yes, absolutely. Hopefully we can make this happen soon.

Indeed, the perception seems to be that getting a certificate from Apple just takes $99 and an email address. If only that were the case...

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[bdkjones]

And think of this from the perspective of the attacker. If you want to compromise an app, it makes sense to go after a popular one that's not signed, right?

I mean, it's POSSIBLE to sign a malware-laced download with a cert, but that's much harder, leaves you open to being traced, and gives Apple an instant kill switch. Are you really going to drop $100,000 on an exploit for that situation? No. You're going to go find some other app that's an easier target. Enter Handbrake.

Sent from my iPhone

On May 17, 2017, at 13:59, Bradley Sepos [e-mail] wrote:

@jbkempf Yes, absolutely. Hopefully we can make this happen soon.

Indeed, the perception seems to be that getting a certificate from Apple just takes $99 and an email address. If only that were the case...

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[bradleysepos]

I'm sorry to hear you feel that way. I guess I feel we've been as transparent as possible. I don't see any excuses or rationalizing. We absolutely think signing our app will improve security and make it harder to socially engineer people into installing a fake. We've discussed the technical limitations of code signing and revocation, sure. Sorry if that's coming off defensive; it certainly isn't meant to be.

We can do better. We should have found the breach ourselves before our users notified us. That's on us. We're doing everything we can to learn from this and we've been transparent about changes we've made to detect threats earlier.

That said, if you had any idea the efforts we've made to get a code signing certificate from Apple, I doubt you would feel we've dragged our feet.

I feel like you want us to admit some wrong or some fault beyond what we've openly admitted. I'm really not sure what to say. We've been super transparent and have admitted various shortcomings. Hopefully that's evident.

[jstebbins]

@bdkjones, Steven's exact words were, "I also likely bypassed the Gatekeeper warning without even thinking about it, because I run a handful of apps that are still not signed by their developers." I.e. in his words, he didn't give it any thought. I believe you when you say you would have noticed the lack of a signature. But I'm inclined to believe Steven and many others are either not as security conscious, or simply will have a lapse of attention during the installation process.

Gatekeeper is one small part of a much larger security picture. Gatekeeper alone is rather weak because it relies so heavily on the user being security aware and alert to the warnings given during installation. Yes, it adds some measure of protection, and yes, we have been and continue to look for a way to sign the HandBrake app. But there are more effective security measures we have taken that protect even the unaware or inattentive.

Let me reiterate. HandBrake is a hobby project. We do this in or free time. We all have other jobs. None of us get paid for working on HandBrake or it's infrastructure. This all means we have to spend our scarce time and resources in the most effective way possible. When security is the issue at hand, the most effective security measures will be considered first.

[bradleysepos]

Some of the proactive measures we've taken in the last year alone partially assisted in mitigating this attack. For instance, we were easily able to integrate strong cryptography into our automatic update functionality (Sparkle) last year. We know for a fact this prevented over 7,000 malicious downloads from being installed, on a technical level.

We were also working on assets monitoring and emergency notifications which would have short-circuited the distribution of compromised assets almost immediately, on a technical level.

So while code signing with an Apple Developer ID certainly has benefits on a social level, it has less of an impact on a technical level when considering this specific incident. It's not the silver bullet some think it is. That said, the various other technical and social benefits to code signing are why we're still pursuing it.

It seems you think we've not moved fast enough, and maybe you're right. We've certainly tried, and as @jbkempf noted, there are barriers to entry for foreign non-profits and unorganized groups. All I can say is, I really do hope we can resolve these issues and begin code signing HandBrake soon. We're certainly moving that direction.

I can only hope that what I and others have said here is seen as truthfulness and not defensiveness or excuses. The last thing we want to do is talk about how awesome we are at security right after a security breach—that would be ridiculous in more ways than one. But it's not fair to suggest HandBrake security is somehow extremely lax. I don't think that assessment fits the facts, but that's why we've tried to be as transparent as possible—so people can draw their own conclusions.

Edit: grammar.

[bdkjones]

I think that's a fair response. I'm glad to see Handbrake moving in the right direction.

Sent from my iPhone

On May 17, 2017, at 15:27, Bradley Sepos [e-mail] wrote:

Some of the proactive measures we've taken in the last year alone partially assisted in mitigating this attack. For instance, we were easily able to integrate strong cryptography into our automatic update functionality (Sparkle) last year. We know for a fact this prevented over 7,000 malicious downloads from being installed, on a technical level.

We were also working on assets monitoring and emergency notifications which would have short-circuited the distribution of compromised assets almost immediately, on a technical level.

So while code signing with an Apple Developer ID certainly has benefits on a social level, it has less of an impact on a technical level when considering this specific incident. It's not the silver bullet some think it is. That said, the various other technical and social benefits to code signing is why we're still pursuing it.

It seems you think we've not moved fast enough, and maybe you're right. We've certainly tried, and as @jbkempf noted, there are barriers to entry for foreign non-profits and unorganized groups. All I can say is, I really do hope we can resolve these issues and begin code signing HandBrake soon. We're certainly moving that direction.

I can only hope that what I and others have said here is seen as truthfulness and not defensiveness or excuses. The last thing we want to do is talk about how awesome we are at security right after a security breach—that would be ridiculous in more ways than one. But it's not fair to suggest HandBrake security is somehow extremely lax. I don't think that assessment fits the facts, but that's why we've tried to be as transparent as possible—so people can draw their own conclusions.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[joshlewis]

Please, please prioritize this, guys. This matters.

[Boggartfly]

Please sign Handbrake. 🙋🏻‍♂️

On Thu 18 May, 2017, 8:19 PM Josh Lewis!, [e-mail] wrote:

Please, please prioritize this, guys. This matters.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/HandBrake/HandBrake/issues/619#issuecomment-302427240,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABoJF-HRQQXHQsYxFs2E73frbCSOCMtvks5r7FqAgaJpZM4MXk2E
.

[sr55]

@joshlewis We are currently in talks with jb at videolan regarding this. Hopefully we can come to an agreement soon and i'll be able to post more information and (hopefully) a short timeline for getting a signed release out.

Our code is already ready. The work to allow sandboxing (required for signing) was mostly done back in January.

Edit Correction: Sandboxing is not required for signing apparently, but we will enable it anyway as it has many benifits.

[joshlewis]

@sr55 That's awesome! I'm so glad to hear this!

[bradleysepos]

428 Sandboxing on macOS

[bdkjones]

Eh? Sandboxing is not a requirement for code-signing. Sandboxing is only a requirement for the Mac App Store.

Sent from my iPhone

On May 18, 2017, at 11:17, Bradley Sepos [e-mail] wrote:

428 Sandboxing on macOS

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[sr55]

Already corrected myself ...

[Jeehut]

Any progress in the talks with VideoLAN so far?

[bradleysepos]

We are currently getting set up to do some initial builds using VideoLAN's systems, which will including code signing.

[Jeehut]

Sounds good. Is it likely to build the nightly builds via VideoLAN's systems as well?

Cause I just downloaded one, since I wanted the most current x265 and it was not signed which made me feel unhappy ... would be great to have them signed, too! 👍

[bradleysepos]

Nightly builds are the first being tested with the help of VideoLAN, but they will likely not be code signed as it's impractical for various reasons (VLC nightlies are not signed).

[Jeehut]

Okay, I see. Well, attackers would reach significantly less people by hacking them anyways, so maybe it's not such a big problem. Also we have hashes for the pro users ... thanks for the quick answer!

[sr55]

@Dschee We sign all our release downloads with a GPG key. So you can authenticate the downloads came from us using our public key. The GPG key is mirrored here on github as well, so should always match. That way if one site ever gets compromised, folks can detect somethings off.

Hashes only allow you to verify the integrity of the file so please don't trust them for authenticating your downloads. Use the GPG signatures.

I'd also argue that you shouldn't trust that just because an app is signed, that
a) It's Safe
b) It's from the original developer.

It's not that hard to get a hold of a stolen cert to sign an app and Apple really hasn't done a good job of making it easy to see who signed the cert. You have to go down to the command line. It's a real shame because it used to be on the old installers (such as the office one) you'd get a lock icon you could click on to verify the parties involved.

So, even when we get this signed, I'd still encourage you to goto the effort of opening the terminal and checking that it's signed using the videolan cert and not a malicious 3rd party cert.

---

Aside from that, The nightly builds won't be code signed. It would put the code signing cert at risk of compromise. The code signing cert is offline and this would require human intervention each night which for obvious reasons, isn't practical.

[Jeehut]

I see. Thanks for the detailed explanation. By "hashes" I meant the GPG signature, sorry for not being precise.

I think what Apple was expecting a few years ago when they started the Mac App Store was that (nearly) all consumer software would be downloaded there sometime. If they had been more open, that could have happened. But for some software it still really is the best and most secure way to distribute their software, in my opinion.

If there was a change that we could get HandBrake online via the Mac App Store, I'd be definitely in favor of that. But I think there could be legal problems that arise without having a legal authority that owns the software. Somebody also proposed to do this for us, even I could do that. But I'm not sure if there could be any disadvantages for me if I put the app on the App Store and somebody else added software that was not licensed. Wouldn't I be responsible for paying the license fees then etc.?

The one thing that came into my mind though was that we could automate the entire App Store Upload process using FastLane – this way it would not be important that the person owning the account has to have time when new releases need to be done. He only would need to be trustworthy enough to not upload anything on himself or delete the app.

[sr55]

Ignoring any potential patient issues when an app is distributed from the US, the real issue is that the Mac App Store License agreement is incompatible with with the GPLv2 license. Even if we could re-license HandBrake to something that would not conflict with Apples Terms, we use many 3rd party libraries that use GPL which we'd still need to abide by.

We'd almost immediately be hit with a copyright infringement claim from our upstream libraries some of which quite strongly uphold their terms. (which is fair enough)

From what I understand, the Microsoft Store actually has clauses that allow for this, so that could potentially be an option down the road.

[Jeehut]

I'm not a lawyer at all, so I basically have no idea, but I just read about this and found this answer which argues (see also the comments) that it should be possible to upload an app onto the Mac App Store so long as the app has a link to a website where the code/software can be obtained with no restrictions. Of course you might already thought about that and agreed, it's not safe enough ... I don't know. Just trying to find a possibility ...

Does VLC Media Player on iOS not include any libraries licensed as GPL?

[bradleysepos]

Interpretations of the GPL aside, Apple has actively removed GPL applications in the past. It's a no-go. Your link is dated; this has been tested in the wild during and since the time those arguments were made.

Does VLC Media Player on iOS not include any libraries licensed as GPL?

libVLC was relicensed LGPL about 6 years ago. The iOS front end is MPL.