I have a C++ Windows app. I sign our installer and my executable, but I don't currently sign my DLLs (such as zlib1.dll). It is not a big deal to sign those as well, but can someone explain what the benefit is? For instance, will my program appear any different to AV or firewall software if all its dependencies are signed? Will users get any different warnings?
Your program will not appear any different to AV or firewall. They will check for signatures on your executable which you have already signed. Signing your dlls makes most sense when you yourself verify those signatures before loading them. This ensures the integrity of all dlls at runtime. It is a recommended secure practice to sign all binaries that you ship and validate their signatures at runtime. If your dlls are to be used by other products then you must sign them as those products will want to verify their authenticity and integrity.
Related
I've noticed something somewhat strange when I ran the Xcode build of my app and then launch the app store build. If I run the xcode build (using development certificates), then run my app through the app store (using production certificates) I get prompted with the following dialog box
MyApp want to use your confidential information stored in "com.myApp in the keychain.
I also get this dialog when I run the app store build first, then the Xcode development build. I believe this dialog appears because both builds have different certificates (could be wrong).
My biggest concern is the user updates the app, will the user see this dialog?
Not sure if this is important, but this is how I save data to the keychain.
[[A0SimpleKeychain keychain] setString:string forKey:#"key"];
Apple's code signing guide has the answers.
I believe this dialog appears because both builds have different certificates
Correct. See Understanding the Code Signature:
The most important internal requirement is the designated requirement, or DR. This rule tells an evaluating system how to identify a particular piece of code. Any two pieces of code that have (and successfully verify against) the same DR are considered to be the same code.
...
Some parts of macOS do not care about the identity of the signer. They care only whether the app is validly signed and stable. Stability is determined through the DR, and does not depend on the nature of the certificate authority used. The keychain system and parental controls are examples of such usage.
From Code Signing Tasks:
Shipping and Updating Your Product
The user’s system considers the new version of your product to be the
same program as the previous version. For example, Keychain Services
does not distinguish older and newer versions of your program as long
as both are signed and the unique Identifier remains constant.
Signing your code with a different certificate makes the system consider it a different app. As long as you sign your releases with the same certificate between versions, you will be fine.
we are developing an application with a Helper Tool - which is installed into the system using SMJobBless. This works as expected; but there is a caveat.
We do frequent automatic deployments - sometimes more than one per week. Everytime the Helper Tool version changes, we re-register it - causing a password prompt. These 2 factors would quickly become irritating to our users.
Is there a way to have the password prompt appear only once, during the initial Helper Tool installation? Could subsequent updates happen without a prompt? Perhaps there is a way to leverage the existing Helper Tool to install a newer version of itself?
Short answer: No. SMJobBless() always prompts for admin credentials. There's no way to stop it from prompting. If you call this API, it'll prompt (or fail).
Longer answer on workarounds:
If your helper tool is running with admin/root privileges, it could theoretically replace itself with a new version. Think very carefully before doing this. Getting this right and maintaining security is very difficult, and the fact that even the major OSes have had vulnerabilities in installer functionality is a strong indicator that the risks of going this route may outweigh the benefits.
If you must proceed, read up on:
Race Conditions, Secure File Operations, and Time of Check vs Time of Use
Apple's Security APIs, particularly SecRequirementCreateWithString and SecCodeCheckValidity.
macOS Code Signing In Depth and the Code Signing Requirement Language
You would have to ensure that your helper tool cannot be tricked into replacing itself with (or executing) malicious code, or you will have opened your software up to being a trivial root exploit vector.
Also note: Regardless of what Apple currently does to verify helper tools installed by SMJobBless, it is conceivable that they could tighten the requirements in the future and refuse to run helper tools that have been modified since they were installed via SMJobBless. The safest method (in multiple respects) is to just call SMJobBless whenever you need to install/update the helper.
We have developed a software in vb.net using Visual Studio 2013. Now we want to build a custom installer with following steps/features:
User Start to install our software.
At 'Enter Serial Key' option, user enters the 16 digit Serial which have we provided.
When clicking 'OK' button, our software connect to our IP and save the Serial Key with some other user's information to our database.
A confirmation Key is returned back to our software.
Software writes a file and save it to the system folder.
It is almost like Adobe or Corel registration process.
We are open to other techniques also which must secure that our software must install on a single machine only.
Please be noted that we are a group of novice programmers(not so advance level), so; if the process is elaborated, it will be very helpful to us.
One-Shot Setups: "A setup is run once, an application can be started again - in order to resolve and debug problems interactively - with meaningful error messages show to the user."
Hence: avoid license validation in the setup.
Short version on licensing.
License Key: Preferring to deal with license keys in your application seems logical for several reasons: the one-shot nature of setups
yields poor reliability (no interactive debugging - poor ability
to resolve problems). The end result is lots of support calls for something very trivial.
Further, the risk of piracy and hacking is a major concern when
exposing a license validation DLL in the setup. And finally
communication over the Internet is difficult with today's setups (proxies, firewalls, etc...) - which is a modern way to validate license
keys (in the future setups might have full Internet access, but be careful assuming too much since corporate users may have lots of restrictions and poor deployment could hurt sales and acceptance of the software for corporate use).
Finally your application must usually support a trial version,
and then you need a license dialog in your application anyway.
Why complicate your setup too?
CAs: Custom actions are complex and vulnerable to failure in general - due to complex sequencing-, conditioning- and
impersonation issues and overall poor debugability. More information:
Why is it a good idea to limit the use of custom actions in my WiX / MSI setups?
Overall Complexity of Deployment: A short, attempted summary of the overall complexity of deployment:
Windows Installer and the creation of WiX
(section "The Complexity of Deployment").
I would remove all licensing features from the setup and add them to the application. Your setup can still write a license to disk or to the registry by passing it to msiexec.exe as a public property -
UPPERCASE properties (or you can "hide" things a little more by using a transform to apply the serial property - it has exactly the same effect as setting the property on the command line). You can also set the LICENSE property from a dialog in the setup when it is run interactively, but my favorite approach is to allow adding the license key unvalidated to the registry in silent deployment mode, and to instead enter the license key directly in the application, and not the setup, for interactive deployments (the above description is for silent deployment):
msiexec.exe /I "C:\Install.msi" /QN /L*V "C:\msilog.log" LICENSE="123-456-789"
This will allow the license to be easily added to each machine in a corporate deployment scenario. The license value is simply written to disk or registry without validation. The application will verify it (more secure than a validation dll in the setup).
There is no need to mess with any complex setup dialogs, but you will need a license dialog in your application as explained below.
As a setup developer you should offer to help implement the feature in the application instead of the setup so it doesn't seem like a case of "passing the buck". This is all for overall software reliability and foolproofness - and several reasons are listed below.
Almost all large corporations deploy MSI files silently, so the setup GUI will be ignored most of the time anyway. You are then simply adding risk and wasting resources if you deal with licenses in the setup.
One drawback: An application run as a non-admin user after installation can not write to HKLM to share a serial between all users on the computer (a setup running with elevated rights can). It must either write to HKCU or the setup must have prepared write access to a specific HKLM location in the registry for the application to write to. I prefer writing to HKCU for each user since the license is then less available for copying by others, and it is kept as user specific data (allows roaming, though that is a hated feature by most IT professionals). However, a HKLM license key written by the application or the setup during installation (as explained above with a public property set) allows all users to share a license when launching the application.
There are several more concrete reasons to keep license handling and validation out of your setup:
A significant number of support requests always result from people who have problems registering their license keys in the setup. A setup is run once, an application can be started again if there are problems. This is more important than you might think for inexperienced users. You also have better features available to handle exceptions and error conditions and whatever unexpected problems may occur in the application.
Serial validation in the setup exposes a validation dll / method that is easily cracked by pirates. You won't prevent piracy by eliminating it from your setup, but at least you make it more difficult. It is more secure in the application if you cloak things a bit (static linking, encryption, obfuscation, putting the validation process online, and / or whatever is done by security professionals that I am unfamiliar with).
Allow application trial version: If the setup needs to support a trial version of the application, you should allow the user to enter a license key if they end up buying the product - preferably without having to re-run the setup or uninstall / reinstall just to add the license key. In other words you will likely need to deal with licensing in your application anyway, why complicate your setup too? More risk, more QA, more potential support requests and potential for multiple required fixes in both setup and application. High total cost?
If your application runs with different editions, what if the user buys an upgraded license? They should just be able to enter it into the license dialog and unlock features if possible and not uninstall and reinstall with all the clunk that involves. For some upgrades this is hard to achieve though, and you often end up with separate setups for different editions.
If the network is using a proxy server for Internet access, you will have problems registering the license over the Internet during the setup (often asked for by marketing). You have more features to check and deal with this in the application - it can try again and wait for access (generally you hook up to IE for automagic proxy configuration if possible). For corporate deployment you need a silent install option too which doesn't validate the key but just writes it to the registry. Trying to access the Internet from a silent install of an MSI is in my opinion a rather extreme deployment anti-pattern. I find it dubious in the setup GUI as well. Do the registration in the application - much less controversial, and you can set up firewall rules to allow it to access the Internet (msiexec.exe is likely blocked - and for good reason). There could also be hardware firewalls and / or security software to deal with that makes Internet access difficult or even impossible without some clunky admin server configuration. This could kill your software from consideration is my experience: "Just get this off our network and application estate - there must be better options - far too clunky and error prone".
UPDATE: As deployment technology matures and becomes more "Internet based" this "truth" may change, and we could end up doing everything "online" with deployment designed specifically to run via online "repositories" for example. We will have to wait and see. For now my opinion is that any setup Internet access requirements are erroneous and undesirable.
Setups that mess with licensing may sometimes cause license data to be deleted during upgrades, patching and migration scenarios due to bugs in the setup. This is a lot more serious at times than you would think - the package might hit thousands of workstations in large companies and be cumbersome to fix.
There is a rather bad "anti-pattern" in the MSI technology itself whereby self-repair or manually triggered repair will reset values in the registry that has been changed by the application. This can wipe out license keys. We see this all the time, and it is the technology's fault. It is just not logical in this area.
There are some fixes - or rather workarounds - for this (use a permanent component, write license from a custom action instead of from a component, etc...), but I find them quite clunky and you have to have a lot of experience to know all the pitfalls - and even experienced users mess this up.
Licensing is a huge corporate headache - often what is desired by a company or corporation is that licensing is centrally managed on a server, and not based on text serial numbers at all (for example concurrent or floating licenses acquired on application launch via the network). Just mentioning this though it is sort of out of scope for the question. In these cases what you specify during installation is generally an IP address pointing to the license server, or just a regular host name to be resolved by WINS or DNS.
As you might have already guessed Windows Installer doesn't provide any out the box feature to handle licencing. But there are commercial licencing solutions which you can go for if affordable.
LogicNP
DESAWARE
Since this is very broad question difficult to explain low level implementation details. I can give you a direction.
First of all you will need a custom UI where user can type in the License/Activation key. There are ways to incorporate a custom UI into windows installer, I have already explained few approaches in SO, refer to the following threads.
Show custom Form during installation
How to add additional custom window to VS setup projects UI flow
By following above approaches you should be able to add a UI where user will type in a key. Once user added the key, he will press Activate button on the custom UI, Button click event handler will invoke the necessary logic to Insert/Validate the activation key entered by the user.
Maybe you could try Inno Setup which is free (even open source) installation system.
It is script based which allows you to tune your installer and perform in it everything!
Creating custom page with entering serial number is really easy, see this example: CustomPage for Serial Number in Inno Setup
and there is also integration for Visual Studio.
I was recently given a VB.NET project for fixing some bugs and creating an installer for it. I was told to use Install Shield LE.
All went well with creating the install script but Windows 8 is giving me a smart screen warning when downloading the application from a web site and trying to install it.
I am aware of Windows 8 policy where popular applications get more "trust points" and become popular but the application is targeted for a fairly small audience of people therefore we can not rely on this option. Even more, people without proper knowledge would be repelled by the warning message and that could cause MS to never raise the trust for the application.
My question is, do I have to sign both - the application and the installer with a certificate? If so how do I sign the installer, as there is a signing tab for the project but I can't find one for the installer.
Bonus points if anyone can tell me if acquiring a proper certificate will remove the warning message telling this isn't a commonly downloaded file and might be dangerous from chrome/IE when downloading the application. There are many threads about this, I know, but most of them suggest adding the site to webmaster tools but that hasn't helped and we're still receiving the message
Thanks.
If I have read your post correctly then you are talking about an application as opposed to a website, and for that you would need a code signing certificate. Certificates that sign websites are different so first and foremost decide what it is that you are producing and want to sign.
Having decided that then you need to decide who you will use to supply your certificate. Typical sources would be VeriSign, Thwaite or Globalsign to name but three. All charge different prices but essentially do the same thing.
Once you have the certificate then the installer that you use to build your application signs the code files you select and the actual installer (msi or exe) itself.
That should eliminate the message that you now see warning people about potentially dangerous files that they are about to download.
I cannot stress enough however that you need to be clear about which type of certificate you need BEFORE you go ahead and buy one. I think from your description you are talking about a code signing certificate but do check first.
Following CAB forum regulation you will need to have an Extended Validation code signing in order to bypass the smart screen filter.
Extended Validation code signing will establish immediate trust with the machine, as you go through a more stringent validation process to obtain it! (or at least that's the rationale behind it!)
I think you can get an extended validation code signing either from SYmantec or GLobalsign.
We've got some code that uses LoadLibrary and GetProcAddress to implement a plugin architecture for one of our products. We ensure that the DLL about to be loaded is signed with our code-signing key.
We're changing the plugin architecture to use COM instead. Is there a way to enforce code-signing (preferably with our certificate) when instantiating a COM object?
You need to do this at the DLL level using the Authenticode API. The standard API is called WinVerifyTrust() and there are samples documented there. There's another KB article number 323809 that gives an example of how to peel other details out of the authenticode information attached to your DLL.
Of course, these APIs expect to be handed a path to the DLL itself whereas in a COM plugin scenario you usually don't directly touch that but instead rely on registration to find the right binary. You can either hand-roll your load scenario (i.e. load the DLL using LoadLibrary() and call DllGetClassObject() yourself) or simply require users of your API to adhere to additional rules such as placing the DLL in a certain location regardless of registration.
Or as Rob Walker suggested, look up the CLSID registration in the registry yourself and use that as the way to find the right DLL to verify.
I don't think you can do this directly, but you could look up the DLL that the CLSID uses in the registry and check its signature before issuing the CoCreateInstance call.