OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: M. Burnett (mburnettxato.net)
Date: Fri Feb 22 2002 - 16:48:38 CST

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    I saw that you got a few responses to your question, but this has
    been asked many times before yet never fully answered to
    satisfaction. So here is the complete explanation, which will
    probably be much more than you want to know about this subject.
    Nonetheless, I thought it would be nice to set the record straight on
    this.

    The confusion here is that we are talking about two TOTALLY DIFFERENT
    types of signatures: code signing (i.e., Authenticode) vs. WHQL
    driver signing. The first one, code signing, is used to authenticate
    the author of an executable. The second is to ensure that a
    particular driver has been certified for use with Windows 2000 or
    Windows XP.

    With code signing, credentials are attached to a binary using an
    individual's or organization's digital certificate. These credentials
    can be verified by looking at the file properties and selecting the
    Digital Signatures tab or using the chktrust.exe tool that is
    included with the Platform SDK and the .NET Framework SDK. With code
    signing, the signature credentials actually become part of the binary
    file. If you open the file in a hex editor you will see the actual
    signature near the end of the file.

    WHQL driver signing, on the other hand, is when Microsoft verifies
    that a driver has been tested to be compatible with Windows 2000 or
    XP and that the files have not changed since testing. Driver
    signatures are included in a catalog file (*.CAT) that is distributed
    with the driver. When Windows checks a driver signature, it checks
    the catalog file to make sure the drivers have not been altered. The
    individual files are not signed, but the .CAT file itself is signed
    with Microsoft's certificate (using the code signing method mentioned
    above). Driver signing only verifies that those particular files have
    been tested to be compatible with Windows 2000 or XP. Driver
    signatures can be verified with the sigverif.exe tool or
    driverquery.exe that comes with Windows XP.

    The primary difference between the two is that code signing is done
    on each binary file with the author's certificate whereas with driver
    signing, only the catalog file is signed and that is done with
    Microsoft's certificate. Code signing is to verify the authenticity
    of a file while driver signing is more intended for system
    reliability.

    So when you get the message box saying that the driver files have not
    been signed, it does not mean that the hotfix itself has not been
    signed. If you look at the signature properties or use the
    chktrust.exe tool, you will see that indeed, the file has been signed
    and is valid.

    However, when the hotfix installs it uses the SetupCopyOEMInf
    function which triggers the checking of driver signatures. Windows
    then looks at the hotfix.inf file to determine the name of the
    catalog file. That catalog file name should appear in hotfix.inf
    under the [Version] section like this:
    [Version]
    CatalogFile=sp3.cat

    Windows then looks for that catalog file (in this case sp3.cat) to
    verify the digital signature (which will be Microsoft's signature).
    If that passes, it verifies the checksums (one MS document calls them
    checksums, another MS document calls them hashes) of each hotfix file
    against the checksums (or hashes) in the catalog file. Since
    hotfixes do have the catalog file entry in the hotfix.inf and that
    catalog file (sp3.cat) is included in the with the hotfix
    distribution, you'd thing that it would pass driver signature
    checking. But it doesn't.

    There are two reasons why the driver signature checking is failing at
    installation: either the drivers themselves are bad or it cannot find
    the catalog file to verify the signatures. Once you install the
    hotfix you can run the sigverif tool and see that the driver files
    are indeed verified at that point so it isn't because the drivers are
    bad. The only explanation is that it cannot find the catalog file
    during installation.

    I did quite a bit of research to find out exactly why this was
    happening and found one possible reason that I have not verified
    myself nor have I informed Microsoft before this e-mail. In the Code
    Signing FAQ located at
    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnw2k
    /html/win2ksignfaq.asp, it says that in addition to adding a
    CatalogFile= entry in the .INF, you must also add the .CAT file in
    the [SourceDiskFile] section. I noticed that hotfix.inf doesn't have
    this entry, so perhaps that is why it is failing. Again, this has
    not been verified.

    Another issue is the KB article Q269651. This article suggests that
    you should set unsigned driver behaviour to silently succeed. I
    would NOT recommend this setting, but would suggest to have it warn
    you instead. In my opinion, this KB article should be changed. In
    Windows 2000, the default setting is to warn but still allow
    installation.

    And how is this setting changed? There are a number of ways:
    1. From the Control Panel, open the System applet, select the
    Hardware tab and click on the Driver Signing button.
    2. From the Administrative Tools, select one of the Security Policy
    snap-ins and change the Unsigned driver installation behaviour under
    Local Policies/Security Options.
    3. Create a Group Policy and change the setting under Local Computer
    Policy\Computer Configuration\Windows Settings\Security
    Settings\Local Settings\Security Options.
    4. Create or modify the values for BehaviorONFailedVerify and Policy
    under HKLM\Software\Policies\Microsoft\Windows NT\Driver Signing.
    5. Create or modify the values for BehaviorONFailedVerify and Policy
    under HKCU\Software\Policies\Microsoft\Windows NT\Driver Signing.
    6. Create the policy in a security template.

    So as you see, the message you get that says that the software you
    are trying to install is not signed is misleading. First of all, it
    has nothing to do with the validity of the hotfix file you
    downloaded. Second, it turns out that the hotfix files actually are
    signed but the hotfix installation is not recognizing this. I'd say
    this is a bug that should be fixed.

    Another important thing to note is that there is no automatic
    checking of the hotfix's signature itself. If you download a
    corrupted or malicious hotfix, there will be no warning when you run
    it. You MUST manually verify every hotfix's signature before
    installing. One interesting thing I just found while writing this is
    that the Digital Signature tab in the file properties may not always
    be correct. I opened up Q314147_W2K_SP3_X86_EN.exe in a hex editor
    and randomly changed data in the binary file. I saved this and
    looked at the signature properties. The Name of Signers field now
    said "Not available" but when I looked at the certificate details it
    said that the digital signature is OK, which was obviously incorrect.
     When I verified that same file with chktrust using the command
    chktrust.exe -v -q Q314147_W2K_SP3_X86_EN.exe I got the following
    message:
    Q314147_W2K_SP3_X86_EN.exe: Failed: The subject is not trusted for
    the specified action

    So perhaps the you cannot trust the Digital Signatures tab in the
    file properties.

    Another thing to consider is what this all means when doing
    unattended installs. When including hotfixes during unattended
    installation, you may be forced to set the DriverSigningPolicy
    setting to ignore in the unattend.txt file. Just be sure to properly
    set the policy after installation.

    So in summary:
     1. Hotfix signatures are not automatically verified, but can
    manually be verified with chktrust.exe
     2. The Digital Signature tab in the file properties dialog may not
    be trustworthy
     3. The invalid signature message during installation has nothing to
    do with the hotfix download itself
     4. The invalid signature message is wrong, and you can verify the
    signatures after installation with sigverif.exe
     5. Microsoft might be able to fix this error message by checking on
    that SourceDiskFile thing
     6. Q269651 has a poor recommendation to set your system to silently
    install unsigned drivers

    And of course, previous recommendations to get the root certificates
    update are also a good idea.

    Mark Burnett
    www.xato.net

    On Thu, 21 Feb 2002 16:32:15 +0800, arsz.chn.tuv.com wrote:
    >
    >Hi,
    >
    >Recently, when I try to download patches from Microsoft I get the
    >messages "Unknown Software Package", "The Software you are trying to
    >install is not signed." "Microsoft cannot guarantee that this
    >software will work with Windows." etc.
    >
    >Is this just temporary or is this the extension of the Mircrosoft
    >"We-don't-test-our-software-and-don't-guarantee-it-is-working-and-if
    >-
    >you-use-it-you-have-to-blame-only-yourself-Policy"
    >
    >towards the patches?
    >
    >What is safer, install no patches or install unsigned patches?
    >
    >Cheers, Andreas
    >
    >