SigCheck reveals Microsoft`s Multiple Failures

   It�s a little hard to explain but the behavior is by design. You have touched on 2 separate but related features: Auto Root Certificate Update and Authenticode. Let me explain.

Certificate Trust Lists (CTL) used by the Auto Root Certificate feature do not follow standard CTL semantics. Normally a CTL signer certificate chain must be valid for the extended key usage Microsoft Trust List Signing (1.3.6.1.4.1.311.10.3.1). However, we wanted to distinguish the Auto Root Certificate Update signer from standard CTL signers so a new EKU Root List Signer (1.3.6.1.4.1.311.10.3.9) was created and to make sure the Auto Root Update signer certificate cannot be used to sign standard CTLs. We left the UI error in place so enterprise admins who stumble upon the auto root update CTL will not put it into group policy and expect it to work. 
The reason signed files are considered valid even though the cert chain has expired is because of timestamping. If the cert chain was valid at the time of the timestamp (which is secured by a counter signature), the file signature is considered valid. This necessary because we cannot expect publishers to keep resigning old files periodically and it was more important that we can limit the validity of individual code signing certificates so a compromised signing key would have a limited lifespan.

ci.dll has a catalog signature and unfortunately sigcheck does not display the catalog file that contains the file hash for ci.dll. If you want to dig deeper, you can use signtool.exe (which ships with the latest version of the Windows SDK). From my Vista SP1 machine:

signtool.exe verify /pa /v /a c:\windows\system32\ci.dll

File is signed in catalog: C:\Windows\system32\CatRoot\{F750E6C3-38EE-11D1-85E5-
00C04FC295EE}\Package_2_for_KB938371~31bf3856ad364e35~x86~~6.0.2.27.cat
Hash of file (sha1): 6741F1F8F3A13485CCA370014D5DC57DAB163B7A

Signing Certificate Chain:
    Issued to: Microsoft Root Certificate Authority
    Issued by: Microsoft Root Certificate Authority
    Expires:   Sun May 09 15:28:13 2021
    SHA1 hash: CDD4EEAE6000AC7F40C3802C171E30148030C072

        Issued to: Microsoft Windows Verification PCA
        Issued by: Microsoft Root Certificate Authority
        Expires:   Tue Mar 15 14:05:41 2016
        SHA1 hash: 5DF0D7571B0780783960C68B78571FFD7EDAF021

            Issued to: Microsoft Windows
            Issued by: Microsoft Windows Verification PCA
            Expires:   Thu Dec 18 14:19:04 2008
            SHA1 hash: 3DF7DF495F722105C67136836B8E7ECE0E51E66F

The signature is timestamped: Fri Feb 29 14:42:22 2008
Timestamp Verified by:

    Issued to: Microsoft Root Authority
    Issued by: Microsoft Root Authority
    Expires:   Wed Dec 30 23:00:00 2020
    SHA1 hash: A43489159A520F0D93D032CCAF37E7FE20A8B419

        Issued to: Microsoft Timestamping PCA
        Issued by: Microsoft Root Authority
        Expires:   Sat Sep 14 23:00:00 2019
        SHA1 hash: 3EA99A60058275E0ED83B892A909449F8C33B245

            Issued to: Microsoft Timestamping Service
            Issued by: Microsoft Timestamping PCA
            Expires:   Tue Jun 12 16:04:51 2012
            SHA1 hash: F9B6EB0ACFFB8DC1B836EE16711BFF423CA1D573

File has page hashes.

Successfully verified: c:\windows\system32\ci.dll
Number of files successfully Verified: 1
Number of warnings: 0
Number of errors: 0

Kelvin

Author	Message Share Topic Printable Version Delicious Digg Facebook Furl Google MySpace Newsvine reddit StumbleUpon Translate Twitter Windows Live Yahoo Bookmarks Topic Search Topic Options Post Reply Create New Topic
kelviny Members Profile Send Private Message Find Members Posts Add to Buddy List Newbie Joined: 31 December 2008 Location: United States Online Status: Offline Posts: 1	Post Options Post Reply Quote kelviny Report Post Quote Reply Topic: SigCheck reveals Microsoft`s Multiple Failures Posted: 31 December 2008 at 6:37pm
	It�s a little hard to explain but the behavior is by design. You have touched on 2 separate but related features: Auto Root Certificate Update and Authenticode. Let me explain. Certificate Trust Lists (CTL) used by the Auto Root Certificate feature do not follow standard CTL semantics. Normally a CTL signer certificate chain must be valid for the extended key usage Microsoft Trust List Signing (1.3.6.1.4.1.311.10.3.1). However, we wanted to distinguish the Auto Root Certificate Update signer from standard CTL signers so a new EKU Root List Signer (1.3.6.1.4.1.311.10.3.9) was created and to make sure the Auto Root Update signer certificate cannot be used to sign standard CTLs. We left the UI error in place so enterprise admins who stumble upon the auto root update CTL will not put it into group policy and expect it to work. The reason signed files are considered valid even though the cert chain has expired is because of timestamping. If the cert chain was valid at the time of the timestamp (which is secured by a counter signature), the file signature is considered valid. This necessary because we cannot expect publishers to keep resigning old files periodically and it was more important that we can limit the validity of individual code signing certificates so a compromised signing key would have a limited lifespan. ci.dll has a catalog signature and unfortunately sigcheck does not display the catalog file that contains the file hash for ci.dll. If you want to dig deeper, you can use signtool.exe (which ships with the latest version of the Windows SDK). From my Vista SP1 machine: signtool.exe verify /pa /v /a c:\windows\system32\ci.dll File is signed in catalog: C:\Windows\system32\CatRoot\{F750E6C3-38EE-11D1-85E5- 00C04FC295EE}\Package_2_for_KB938371~31bf3856ad364e35~x86~~6.0.2.27.cat Hash of file (sha1): 6741F1F8F3A13485CCA370014D5DC57DAB163B7A Signing Certificate Chain: Issued to: Microsoft Root Certificate Authority Issued by: Microsoft Root Certificate Authority Expires: Sun May 09 15:28:13 2021 SHA1 hash: CDD4EEAE6000AC7F40C3802C171E30148030C072 Issued to: Microsoft Windows Verification PCA Issued by: Microsoft Root Certificate Authority Expires: Tue Mar 15 14:05:41 2016 SHA1 hash: 5DF0D7571B0780783960C68B78571FFD7EDAF021 Issued to: Microsoft Windows Issued by: Microsoft Windows Verification PCA Expires: Thu Dec 18 14:19:04 2008 SHA1 hash: 3DF7DF495F722105C67136836B8E7ECE0E51E66F The signature is timestamped: Fri Feb 29 14:42:22 2008 Timestamp Verified by: Issued to: Microsoft Root Authority Issued by: Microsoft Root Authority Expires: Wed Dec 30 23:00:00 2020 SHA1 hash: A43489159A520F0D93D032CCAF37E7FE20A8B419 Issued to: Microsoft Timestamping PCA Issued by: Microsoft Root Authority Expires: Sat Sep 14 23:00:00 2019 SHA1 hash: 3EA99A60058275E0ED83B892A909449F8C33B245 Issued to: Microsoft Timestamping Service Issued by: Microsoft Timestamping PCA Expires: Tue Jun 12 16:04:51 2012 SHA1 hash: F9B6EB0ACFFB8DC1B836EE16711BFF423CA1D573 File has page hashes. Successfully verified: c:\windows\system32\ci.dll Number of files successfully Verified: 1 Number of warnings: 0 Number of errors: 0 Kelvin

dmex Members Profile Send Private Message Find Members Posts Add to Buddy List Newbie Joined: 31 December 2008 Location: Australia Online Status: Offline Posts: 1	Post Options Post Reply Quote dmex Report Post Quote Reply Posted: 31 December 2008 at 1:52pm
	Hello, I have been using sigcheck to verify Digital Signatures and found very troubling information about the state of Microsoft`s code signing and it seems CAPI2 has a highly flawed implementation on every version of Windows... At this time, the Certificate Trust List update found on Windows Update being offered to every last Microsoft Windows based system is Signed using an Invalid Signature (Failed root list from auto update cab at: http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab with error: The data is invalid.) Looking inside the cabfile you can find the authroot.ctl update and see how its signature is signed using an invalid Certificate... If you look at the 'Trust List' tab you can see hundreds of corrupted Entries (once compared with the last CTL update) the problem with this situation is that every last Windows based machine is trying to silently download/install this corrupted CTL and it has the potential to corrupt the entire Certificate Store on every last Windows based machine...I have reported this to Microsoft and they say it will be fixed sometime soon, however it doesn't end there... Browsing to the 'C:\Windows\System32\catroot\' folder with sigcheck revealed another serious question about Microsoft`s code signing practices as it seems their are hundreds of digitally signed files showing as 'OK' even though they have all expired, even some expired over a year ago and are still showing as 'OK' (I highlighted the areas of interest) Even Microsoft's Code Integrity Module (C:\Windows\System32\CI.dll) has this same expired signature yet it still shows as "OK" I have checked our corporate network and both these problems affect all our XP and Vista (both 32bit and 64bit) machines and raises some serious questions about Digital Signing on Windows based systems.... 1st, How does a corrupted CTL update manage to be offered on WindowsUpdate for over two months without anyone noticing the CTL list update is invalid? 2nd, Why does Windows report all these certificates as 'OK' even though they have expired? 3rd, What does this mean about the accuracy of Windows digitial certificate verification and can it be trusted consdering two current major failures? All of our machines show these same results...The CTL update on Windows Update (link above) as being corrupt and also hundreds of multiple system files (C:\Windows\System32\CI.dll and all the security catalogues found here 'C:\Windows\System32\catroot\' ) as showing OK even though their cerificates have expired? Both these 'glitches' raise some serious questions about how well anyone including our company can trust Microsofts CAPI implementation for Digitial Certificates, can anyone else verify my comments or possibly explain this with more detail? Steven Edited by dmex - 31 December 2008 at 2:31pm