An alternative guide to code signing

OK, so you go to some site and order a certificate. This process is by
itself complicated enough to where several people have felt the need to
do write-ups about how to do it. Including screen shots with lots of red
circles and warnings. Do this! Don't do that! Remember this! Don't
forget that!

Next, you stress your cc by paying a churlish amount of money.

Getting this far, you've got several passwords to keep track of. And
you're doomed (= you have to pay more money) if you forget any one of them.

Now, some robot does an indifferent survey of your company. This may
include a request for you to call a machine that doesn't even talk back
to you!

When you finally receive the mail with the collection code you must
follow the mysterious instructions herein and go to obscene places in
your browser to export a certain file. This file has an extension that
doesn't necessarily match your imagination of it being a .pfx or a .p12
or a .crt or a .key or a .whatever file when you're done. So you search
the internet for instructions on how to convert from one format to
another (which btw may take you to many interesting places). With some
luck you find what you're looking for - and maybe you even understand
the suggested procedure.

Now it's time to put your newly acquired certificate to work. This -
among many other intransparent actions - involves the use of a MS
program that you don't have. And you cannot just go and download it from
somewhere! No no, at best it's part of a many-gigabyte download of some
SDK that you don't really need. Having resolved this little problem you
must now ...

Arrrghh ....

Who on earth came up with this whole concept????

I've got the Code signing blues!

Peter

Hi Peter,

> Arrrghh ....
>
> Who on earth came up with this whole concept????

And then if someone messes with your EXE the certificate is invalidated,
BUT the user has no clue about it! I code signed a program, then opened
it up in a hex editor and changed some text resources and such. Ran
fine, no warnings, no nothing. Checked the certificate and it said
something like "invalid checksum" or some such thing. So, IMHO, the
value of those things is very limited to the average computer user.

But it sure makes some companies a ton of money!

Best regards,

--
Arnor Baldvinsson
Icetips Alta LLC

I don't know much about SB, but doesn't it have a function (can't remember the
name) that lets you validate the integrity of the installer as it is running
and abort if it has been tampered with?

Liam

Liam,

> I don't know much about SB, but doesn't it have a function (can't remember the
> name) that lets you validate the integrity of the installer as it is running
> and abort if it has been tampered with?

Integrity of the installer, not the installed program, that's
different. I did what Arnor did a few years back and was amazed that
no notice was provided to the user unless they went to properties and
checked the certificate directly.

I believe there is a way, programmatically to do this within you EXE's
but I don't recall how.

--
Lee White

RPM Report Viewer.: http://www.cwaddons.com/products/rpm/
RPM Review........: http://www.clarionmag.com/cmag/v11/v11n06rpm.html
Report Faxing.....: http://www.cwaddons.com/products/afe/
---Enroll Today---: http://CWaddons.com

Creative Reporting: http://www.CreativeReporting.com

Product Release & Update Notices
http://twitter.com/DeveloperPLUS

Windows 8 brings us "The Oval, Bumper Car, Roller Coaster of Wait!"
And, now, Windows 10 brings us "The Inch Worm, Bumper Car of Wait!"

Hi Liam,

> I don't know much about SB, but doesn't it have a function (can't remember the
> name) that lets you validate the integrity of the installer as it is running
> and abort if it has been tampered with?

Correct, but that doesn't prevent installed applications from being
tampered with. There are APIs to verify certificates, but the last time
I looked at them they looked nasty<g> IMO, the OS should verify it,
since it's the OS that requires those darn things. I'm not a fan of
code signing;)

Best regards,

--
Arnor Baldvinsson
Icetips Alta LLC

That's amazing!

Peter

Liam,

> I don't know much about SB, but doesn't it have a function (can't remember
> the name) that lets you validate the integrity of the installer as it is
> running and abort if it has been tampered with?

Yes, absolutely.

1. General Information -> Advanced Settings -> Enable Installer Integrity
Check

-and/or-

2. For super duper high-security systems:

a.) Get File Info -> Verify Trust [Code-signature] -- This option lets you
retrieve the code-sign status of your own file.

b.) Get File Info -> Get Trust [Code-signature] -- For example, for updates
to make sure that only YOUR updates get applied. This option lets you
retrieve certificate specific information from a code-signed file.

http://www.lindersoft.com/forums/sho...8775#post78775

We have developed this function for the U.S. Government (to handle ultra
secure web updates).

Background: Software product deployed with SetupBuilder to a VERY large user
base. Web Update is used to bring the software to the latest version
(live-update functionality). The full and the web update install images are
code-signed. If a new version is available, the Web Update client downloads
and launches the update.

IT security specialists analyzed the update strategy for potential
vulnerabilities and reported that they need to be prepared for the following
type of action: an attacker gets control over the web update server and
redirects the traffic to an external server to download and execute
malicious code (which is very unlikely, but in theory, it's possible).

The "Verify Trust [Code-signature]" SetupBuilder function lets you retrieve
the code-sign status of a downloaded file. But the WinVerifyTrust Windows
function can only ensure that a binary is signed by some key that is part of
Microsoft's chain of trust.

No problem. There is another "Get Trust [Code-signature]" SetupBuilder
function that lets you optionally perform the Authenticode verification AND
retrieve code-signing certificate specific information to ensure the update
install image was signed by your private key (e.g. based on the serial
number or the code-signing certificate issuer name). This function allows
you to build a customized wupdate.exe (or wucheck.exe) and check whether a
downloaded web update installer package is code-signed with a specific
code-signing certificate before the update is launched.

Friedrich

--
Friedrich Linder
Lindersoft | SetupBuilder | www.lindersoft.com
954.252.3910 (within US) | +1.954.252.3910 (outside US)

--SetupBuilder "point. click. ship"
--Helping You Build Better Installations
--Create Windows 10 ready installations in minutes
--Official COMODO Code Signing and SSL Certificate Partner

Arnor,

> And then if someone messes with your EXE the certificate is invalidated,
> BUT the user has no clue about it! I code signed a program, then opened
> it up in a hex editor and changed some text resources and such. Ran
> fine, no warnings, no nothing. Checked the certificate and it said
> something like "invalid checksum" or some such thing. So, IMHO, the
> value of those things is very limited to the average computer user.

And that's why installing into the protected "Program Files" folder tree is
so fundamentally important -- to make sure that non-elevated running
applications can't manipulate your installed applications.

Here is how it works. See attached screenshots.

An application requests administrator execution level privileges to launch
elevated and to get access to protected Windows resources. For example, the
SETUP.EXE application. The UAC elevation prompt (blue) for perfectly
code-signed applications comes up and displays the verified publisher.

Now let's change a single byte in that code-signed application. BANG! The
elevation prompt (orange) for non-signed "requireAdministrator" applications
comes up. The publisher is "Unknown". And here is where *I* always stop.
I would never ever in my life grant elevated privileges to an application
that does not have a valid signature. Never!

And then there is the "User Access Control: Only elevate executables that
are signed and validated" Group Policy. A user with a high level of
security should have this policy ENABLED. It is disabled by default (the
marketing people at Microsoft had the power) and this is a major security
flaw (IMO). If this policy is enabled, the tampered, hacked, or incomplete
application does not even start.

Okay, now lets change a single byte in a code-signed application that
requests "asInvoker" execution level privileges to run non-elevated by
default. Nothing happens. And again, the marketing idiots at Microsoft had
the power. Why? Because there are so many lazy developers out there who do
not code-sign applications (to protect their customers). So some developers
have to go the extra mile and implement their own code-signature check to
detect tampered or hacked application files.

In 2011 (for Windows 8) and 2014 (for Windows 10) I sent two suggestions to
Microsoft:

1. Add a "User Access Control: Only start "asInvoker" executables that are
signed and validated" Group Policy; enabled by default.

2. Enable the "User Access Control: Only elevate executables that are signed
and validated" Group Policy by default.

Microsoft did not listen because the marketing people have the power. Too
many legacy applications out there, too many developers who do not follow
the Windows development guidelines.

Friedrich

Hi Arnor,

> IMO, the OS should verify it, since it's the OS that requires those
> darn things. I'm not a fan of code signing;)

Microsoft programmers in Redmond said "YES, EXACTLY. The OS should verify
it!" Microsoft marketing said "Holy sh%*, NOOOOOO." Windows users said
"But I would like to run my app from 1988 in Windows 10, so NOOOOOO."

The one who focuses on the customer and marketing always wins, right? <g>

Friedrich

Peter,

> Arrrghh ....
>
> Who on earth came up with this whole concept????
>
> I've got the Code signing blues!

And please don't forget that your new certificate does not have any
"reputation" <g>. Files signed with a brand new code signing certificate
need to build reputation, you'll have to earn trust. Reputation is
generated and assigned to digital certificates as well as specific files.
But digital certificates allow data to be aggregated and assigned to a
single certificate rather than many individual programs.

There's absolutely no way around code-signing <g>

Friedrich

Thanks Friedrich!

Liam

Lazy developers!!!

The major application suite I work with for my primary client (who have
several million dollars involved in the license fees alone) uses a writeable
INI file in c:\Windows (STILL!) and suggests that all users be given Full
Control to the suite's installation folder, and defaults to having all its
MSSQL access done using the SA account.

And of course... none of their installers are code-signed ("Unidentified
publisher wants access to your machine"), let alone their apps or DLLs.

But then, a lot of their documentation screen shots show Windows XP.....

Sigh..........


jf