Page 1 of 2 12 LastLast
Results 1 to 10 of 12

Thread: An alternative guide to code signing

  1. #1

    Default 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

  2. #2

    Default Re: An alternative guide to code signing

    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

  3. #3

    Default Re: An alternative guide to code signing

    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

  4. #4

    Default Re: An alternative guide to code signing

    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!"

  5. #5

    Default Re: An alternative guide to code signing

    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

  6. #6

    Default Re: An alternative guide to code signing

    That's amazing!

    Peter

  7. #7

    Default Re: An alternative guide to code signing

    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

  8. #8

    Default Re: An alternative guide to code signing

    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
    Attached Images Attached Images      

  9. #9

    Default Re: An alternative guide to code signing

    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

  10. #10

    Default Re: An alternative guide to code signing

    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

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
  •