An alternative guide to code signing

[NewsArchive]

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