Results 1 to 10 of 12

Thread: An alternative guide to code signing

Threaded View

Previous Post Previous Post   Next Post Next Post
  1. #10

    Default Re: An alternative guide to code signing


    > 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

    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.

    Attached Images Attached Images      

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts