We publish an update patch to our software package in a single executable file. The file is signed with an Authenticode digital signature, using the certificate issued to us. The file is downloaded to Windows XP or Vista systems that our customers operate, where they run it in order to update our software.
Our PCI compliance auditor has asked us to protect against the following situation:
After downloading our executable file, a malicious person alters the file. An observant person would be able to check the properties for the file and determine that the signature is no longer valid.
The malicious person places the altered executable somewhere that an unsuspecting user could run it.
An unsuspecting user runs the altered file, releasing unspecified havoc.
The auditor contends there is a way (or ought to be a way) to prevent the file from running at all if the signature is not valid.
Do you know how this can be accomplished?
MSDN has some interesting articles about this subject:
Verifying the Signature of a PE File in C
How To Get Information from
Authenticode Signed Executables
Related
https://learn.microsoft.com/en-us/windows-hardware/drivers/install/cross-certificates-for-kernel-mode-code-signing
As per the link above you can sign a kernel model driver with your code signing certificate, then sign it again with the cross signed cert. This is required for a kernel mode driver.
The question is, is there any reason/benefit of signing your exe/msi packages with the cross signed certificate as well?
If there isn't any benefit, why is it required for a kernel mode driver? How does it make it more secure?
Cross signing gives an extra level of trust, which is important for kernel mode drivers. Cross signing provides extra trust because it's very unlikely that both certificate authorities would have been compromised.
For EXE's and MSI's it would seem that cross signing means your executable can still be trusted in the event that one of the authorities were compromised.
EDIT:
My personal experience related to this was with Authenticode signed assemblies and how they can be slow to load (you haven't said if your EXE is a .NET assembly). See here https://blogs.msdn.microsoft.com/shawnfa/2005/12/13/authenticode-and-assemblies/
Assembly Load Performance
When the CLR loads an assembly which has an Authenticode signature, it
will always try to verify that signature. This is in contrast to the
Windows loader, which will verify the signature of a file only in
specific instances, such as when the file is an ActiveX control. This
verification can be quite time intensive, since it can require hitting
the network several times to download up to date certificate
revocation lists, and also to ensure that there is a full chain of
valid certificates on the way to a trusted root. So, when an
Authenticode signature is applied to an assembly it's not unheard of
to see a several second delay while that assembly is being loaded.
Also note that the optimization applied to strongly named assemblies,
where the strong name signature is not verified if the assembly is
being loaded from the GAC is not applied to Authenticode signatures.
Since Authenticode provides the ability to revoke a certificate, we
cannot assume that because the assembly's Authenticode signature was
valid when it went into the GAC it will remain valid every time we
load it.
To me that's saying that if your EXE is built by .NET (ie. it's an assembly) then probably the more CA's it's signed by, the slower it might load. If it's not .NET, or an ActiveX control (or 'some instances), then there will be no delay.
I developed a Windows app using C++ and QT library. The app doesn't require elevated privileges to run.
I'm going to distribute my app as an MSI installer downloaded from a website. The installer will be signed using my signed certificate.
However, I haven't signed the EXE file and I don't see any issues with that. There's no security warning shown when I start the app after the installation.
So the question is, should I sign the EXE file as well? If I don't sign it, will there be any issues?
For example, after I downloaded the Dependency Walker tool, it shows me a security warning about an unverified publisher every time I run it. My EXE file isn't signed as well, but I don't see any warnings.
I'm wondering if I can encounter any issues if I release the unsigned EXE file within my signed MSI installer.
It would certainly be preferable for the EXE file to be signed, but it is not ordinarily mandatory. Windows will not warn users when running an unsigned executable file unless the file has a zone identifier or is being elevated ("run as administrator").
However, unsigned files are more likely to experience false positives from security software, may cause users or administrators to be concerned about the trustworthiness of the file and/or process, and are more difficult for administrators to whitelist in high-security environments.
Generally speaking, if the container (the MSI file) is signed and therefore has not been tampered with between its creation and use by the customer then you can trust the content when it gets extracted. Signing is something used mostly at deployment, whether via MSI install or installing a driver, or when you transfer the file to someone else. If there were a scenario where you'd ask some other person or company to use that executable outside of installing it from the MSI file they would probably prefer that it be signed to verify that it's from you and your company.
I have acquired and deployed a digital code signing certificate. I have added it to the installation program for a Windows application, signing the InstallShield setup.exe file and the msi file. Everything works perfectly in the installation program.
My application is installed as a single exe file along with a complied html help file.
Is the best practice to digitally sign the exe file in addition to the Windows installation program?
Yes. You should sign the executable as well.
You should also ensure you use a time-stamp server if possible when signing too. Thus users of your application know the code came from a valid source, and the certificate was valid when it was signed. (The time-stamping means users can check the signing is valid after the expiry date of your certificate - i.e. the signature will be valid for all time.)
I'm unclear how a driver should be signed in my specific circumstances.
OpenVPN has a tap driver that consists of tap0901.sys, tap0901.cat and OemWin2k.inf files.
When I install it using "devcon install OemWin2k.inf tap0901" on my win7 64-bit, it installs silently, without scary warnings.
I renamed the driver to have a different name ogtap100 (by renaming files to ogtap100.sys, ogtap100.cat and replacing "tap0901" strings in OemWin2k.inf to "ogtap100", as per http://community.openvpn.net/openvpn/wiki/ManagingWindowsTAPDrivers and comments in OemWin2k.inf).
However, when I run "devcon install OemWin2k.info ogtap100" on the renamed driver, I get big scary warning from Windows that the driver comes from unknown source. It'll install but I plan to ship it as part of my app, so big scary warning is not good.
When I run "signtool verify /v ogtap100.cat", I get: "SignTool Error: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider." even though it also says that root certificate is "Issued to: DigiCert High Assurance EV Root CA".
I've tried re-signing (signtool sign /f cert.pfx ogtap100.cat) with my own certificate (which works when signing regular .exe files) but I get the same scary warning.
What am I missing?
Can it be sth. to do with catalog (.cat) file?
I've read http://msdn.microsoft.com/en-us/windows/hardware/gg463050 but it assumes that I'll generate .cat file myself. I already have .cat file from OpenVPN. Do I have to re-generate it after renaming files and OewmWin2k.inf? If yes, how?
1) Did you ensure that you got the high assurance digicert certificate? The standard one they issue isn't meant for drivers. It is simple to change...
https://www.digicert.com/code-signing/driver-signing-in-windows-using-signtool.htm
2) If you download the Windows 7 DDK and do a little 'reading the intent and the code' as opposed to just following the instructions, you can succeed at building your own driver (cat and sys files), properly renamed and signed.
https://community.openvpn.net/openvpn/wiki/BuildingTapWindows
Look at the OemWin2k.inf generated for some strong hints for renaming. Note: The Time stamp needs to be correct, and it is in (the ridiculous) mm/dd/yyyy format.
3) As for the warning message, at least you can get it to properly display your company name, and Windows will accept (and not disable) the properly signed driver.
For details about driver signing, check out
https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/0b00c9d4-dff9-4fbe-b741-768c9b39349c/practical-windows-code-and-driver-signing-discussion?forum=wdk
This is a summery that points to some reference docs. Generating the .cat file from the inf is simple.
Check out the syntax and order of operation. I'm also using a Digicert certificate. make sure you have one issued for driver signing and pay attention to the make sure the cross certificate is correct.
The build script uses the inf2cat method, so if you are following the WHOLE instructions (and searching for the stuff in the settings that the inf didn't tell you about ... look for constants) then you are generating the .cat file.
For my install, I figured that the .sys file should be signed before generating the .cat and signing it.
Also, make sure your pc has all the windows updates. This actually did work to 'fix' a pc that had the same error signature. (It didn't have the required certificate to validate the cross certificate, which it automatically downloaded.)
We offer a Windows program downloadable as an InstallShield EXE from our website.
When someone running IE9 attempts to download and run our software, they see the following message at the bottom of their screen:
PROGRAMNAME.exe is not commonly downloaded and could harm your computer.
[DELETE] [ACTIONS] [VIEW DOWNLOADS]
I've read http://blogs.msdn.com/b/ie/archive/2011/03/22/smartscreen-174-application-reputation-building-reputation.aspx
It suggests:
Digitally sign your programs with an
Authenticode signature.
Ensure downloads are not detected as
malware.
Apply for a Windows Logo.
We've done all three things. Our EXE is digitally signed with an authenticode signature (and the bar above the warning message is orange, not red, indicating that IE9 recognized and verified the signature). Our download is not detected as malware by any antivirus program we've tried. And we have applied for and received a Windows Logo.
As yet, most of our customers are not using IE 9. But this is very troublesome to those who do. Is there anything else we can do about this, or do we just have to wait until a critical mass of customers have downloaded this software before this message will go away?
(Does that mean when we release a new version, all IE 9 users will get this message again until enough of them have downloaded it?)
UPDATE 2011-06-14:
Thanks, #EricLaw-MSFT. URL is http://dakim.dakiminc.netdna-cdn.com/DakimBrainFitness.exe . (It's found on the "Download Free Trial" button on http://www.dakim.com .)
We've only been offering downloadable trials for a short while. Our primary distribution method is installation DVDs.
Extended Validation Code Signing Certificates don't suffer from the need to build reputation slowly according to this post:
Reputation is generated and assigned to digital certificates as well as specific files. Digital
certificates allow data to be aggregated and assigned to a single certificate rather than many
individual programs. Although not required, programs signed by an EV code signing certificate can immediately establish reputation with SmartScreen reputation services even if no prior reputation exists for that file or publisher. EV code signing certificates also have a unique identifier
which makes it easier to maintain reputation across certificate renewals. Only Authenticode
Certificates issued by a CA that is a member of the Windows Root Certificate Program can establish
reputation.
At this time, Symantec and DigiCert are offering EV code signing certificates.
In an effort to improve my answer, I've added a link to a similar question I asked and eventually answered myself.