none
Hang when launching digitally signed executable RRS feed

  • Question

  • We have a weird problem on 2 PCs with running a digitally signed 120 Mb executable.

    If user launches a digitally signed .exe - then the launching host (e.g. Explorer or cmd.exe) will enter infinite (endless) cycle constantly opening/closing HKLM\System\CurrentControlSet\Control\Cryptography\Providers and HKLM\System\CurrentControlSet\Control\Cryptography\Configuration registry keys. The call stack indicate that host process is sitting inside CreateProcess function (more specifically - inside NtCreateUserProcess), and the target process is "partially created". E.g. it is visible in Task Manager, but there is no "Process created" event in Process Monitor, and any attempt to open target process will hang the tool which attempts to open it.

    The launch process for Explorer/CMD goes like this:

    1. Checking HKLM\SOFTWARE\MICROSOFT\WINDOWS NT\CURRENTVERSION\Image File Execution Options (not exists)
    2. Reading entire .exe by 32 Kb chunks
    3. Reading registry keys under HKLM\System\CurrentControlSet\Control\Cryptography\ and enumerating HKLM+HCU\SOFTWARE\MICROSOFT\SystemCertificates\Disallowed\Certificates
    4. Endless cycle with reading the above mentioned registry keys starts right after ending enumeration of HKU.DEFAULT\SOFTWARE\Policies\Microsoft\SystemCertificates\Disallowed\Certificates

    The digital certificate is a usual SHA1-RSA certificate for code signing issued by COMODO. Signed executable is time-stamped. The problem is not in a particular executable, as all other executables signed with this certificate have the same issue. Other signed executables seems to run OK.

    What we have tried:

    1. File hash is OK.
    2. Both PCs have MalwareBytes installed.
    3. Disabling anti-virus and firewall does not solve the issue.
    4. Safe mode solves the issue.
    5. Certificate is OK, not expired, not revoked, certutil -f -urlfetch -verify does not find any issue.
    6. Certificate's hash is not listed in the above mentioned enumerations of various Disallowed\Certificates registry keys.
    7. Uninstalling MS14-066/KB2992611 does not help.

    Any ideas?

    Friday, December 12, 2014 12:28 PM

Answers

  • We found the reason for this.

    It is indeed a problem with Malwarebytes tool. Its driver (mbamchameleon.sys) injects into CreateProcess call and cause infinite loop during check for digital signature of some signed executables.

    https://support.eurekalog.com/index.php?/Knowledgebase/Article/View/67/4/installer-hangs-on-launch

    • Marked as answer by GunSmoker Tuesday, February 10, 2015 4:40 PM
    Tuesday, February 10, 2015 4:40 PM

All replies

  • Hello, I don't know if you have a problem similar to one I've experienced recently, however it can be an idea to check. Recently I've integrated inside my .net application a digitally signed assembly. When loading my application, the .net framework tries to load the signed assembly and when it try to verify the digital signature, it also tries to verify revocation status through OCSP or by downloading the CRL... obviously my application runs inside an intranet and the OCSP/CRL services of the assembly supplier are on Internet, so there are always 30 seconds of "hanging" every time the user loads the application, or worst, in case of no network, also longer times.

    I suggest you to check with Fiddler if there is some connection to OCSP/CRL web sites, if yes, my trick is to put the hostnames in the workstation hosts file on 127.0.0.1

     

    DieguZ

    Friday, December 12, 2014 4:13 PM
  • DieguZ, this does not seem to be a problem. PC has internet connection, we tried to shut down firewall, certutil sucessfully checks revocation status, also CRL URL is accessible via web-browser.
    Monday, December 15, 2014 8:20 PM
  • Pavel A, this does not depend on executable. An empty application signed with this specific certificate have the same behaviour.

    We tried to disable Malwarebytes, but did not tried clean machine + Malwarebytes. I do not suspect it in particular, just trying to figure out what is common between these two machines.

    Monday, December 15, 2014 8:23 PM
  • I am unable to reproduce this issue on clean VM with Malwarebytes installed, so it is probably not the reason.
    Monday, December 15, 2014 8:36 PM
  • Sorry for that, another thing that comes to my mind that can cause some problems is the CA trust-chain of the workstation. Sometimes if the RootCA and SubCA of the signer certificate is missing or installed twice, Windows makes some problems.

    Hope it helps.


    DieguZ

    Tuesday, December 16, 2014 8:34 AM
  • DieguZ, and how can I check it?

    Right click on .exe and view digital signature and certificate does not reveal any problem. Certificate is disaplayed as OK, you can view trust chain certificates OK.

    Again, if I extract certificate (public key) from digital signature of .exe and check it with certutil - it will find no issues. 

    Here is the output from certutil (masked e-mail's @ with _):

    Issuer:
        CN=COMODO Code Signing CA 2
        O=COMODO CA Limited
        L=Salford
        S=Greater Manchester
        C=GB
    Subject:
        CN=EurekaLab s.a.s. di Fabio Dell'Aria & C.
        O=EurekaLab s.a.s. di Fabio Dell'Aria & C.
        STREET=Via San Benedetto il Moro, 14
        L=Palermo
        S=Italy
        PostalCode=90126
        C=IT
    Cert Serial Number: 1998b8fd6b038a439c32f32caf35c69b
    
    dwFlags = CA_VERIFY_FLAGS_ALLOW_UNTRUSTED_ROOT (0x1)
    dwFlags = CA_VERIFY_FLAGS_IGNORE_OFFLINE (0x2)
    dwFlags = CA_VERIFY_FLAGS_FULL_CHAIN_REVOCATION (0x8)
    dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
    dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
    ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN (0x20000000)
    HCCE_LOCAL_MACHINE
    CERT_CHAIN_POLICY_BASE
    -------- CERT_CHAIN_CONTEXT --------
    ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
    ChainContext.dwRevocationFreshnessTime: 1 Days, 10 Hours, 29 Minutes, 55 Seconds
    
    SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
    SimpleChain.dwRevocationFreshnessTime: 1 Days, 10 Hours, 29 Minutes, 55 Seconds
    
    CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=0
      Issuer: CN=COMODO Code Signing CA 2, O=COMODO CA Limited, L=Salford, S=Greater Manchester, C=GB
      NotBefore: 2012-11-30 03:00
      NotAfter: 2017-12-01 02:59
      Subject: CN=EurekaLab s.a.s. di Fabio Dell'Aria & C., O=EurekaLab s.a.s. di Fabio Dell'Aria & C., STREET="Via San Benedetto il Moro, 14", L=Palermo, S=Italy, PostalCode=90126, C=IT
      Serial: 1998b8fd6b038a439c32f32caf35c69b
      SubjectAltName: RFC822 Name=support_eurekalog.com
      b8 90 d6 c4 c6 67 7a b2 7d 99 1e 8b 66 52 2c cd e0 87 2f 11
      Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
      Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
      ----------------  Certificate AIA  ----------------
      Verified "Certificate (0)" Time: 0
        [0.0] http://crt.comodoca.com/COMODOCodeSigningCA2.crt
    
      ----------------  Certificate CDP  ----------------
      Verified "Base CRL (1264)" Time: 0
        [0.0] http://crl.comodoca.com/COMODOCodeSigningCA2.crl
    
      ----------------  Base CRL CDP  ----------------
      No URLs "None" Time: 0
      ----------------  Certificate OCSP  ----------------
      Verified "OCSP" Time: 0
        [0.0] http://ocsp.comodoca.com
    
      --------------------------------
        CRL 0:
        Issuer: CN=COMODO Code Signing CA 2, O=COMODO CA Limited, L=Salford, S=Greater Manchester, C=GB
        04 3e 3d 43 83 52 b6 ce c5 bb 98 7d b7 41 33 05 e0 07 5a 4c
      Issuance[0] = 1.3.6.1.4.1.6449.1.2.1.3.2 
      Application[0] = 1.3.6.1.5.5.7.3.3 Code Signing
    
    CertContext[0][1]: dwInfoStatus=102 dwErrorStatus=0
      Issuer: CN=UTN-USERFirst-Object, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, S=UT, C=US
      NotBefore: 2011-08-24 03:00
      NotAfter: 2020-05-30 13:48
      Subject: CN=COMODO Code Signing CA 2, O=COMODO CA Limited, L=Salford, S=Greater Manchester, C=GB
      Serial: 10709d4ff55408d7306001d8ea9175bb
      b6 47 71 39 25 38 d1 eb 7a 92 81 99 87 91 c1 4a fd 0c 50 35
      Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
      Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
      ----------------  Certificate AIA  ----------------
      Verified "Certificate (0)" Time: 0
        [0.0] http://crt.usertrust.com/UTNAddTrustObject_CA.crt
    
      ----------------  Certificate CDP  ----------------
      Verified "Base CRL (3898)" Time: 0
        [0.0] http://crl.usertrust.com/UTN-USERFirst-Object.crl
    
      ----------------  Base CRL CDP  ----------------
      No URLs "None" Time: 0
      ----------------  Certificate OCSP  ----------------
      Verified "OCSP" Time: 0
        [0.0] http://ocsp.usertrust.com
    
      --------------------------------
        CRL 3898:
        Issuer: CN=UTN-USERFirst-Object, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, S=UT, C=US
        4f 4f fc 29 44 da af fb 6e 2c ca ad d5 d7 0f 25 84 83 7d 56
      Application[0] = 1.3.6.1.5.5.7.3.3 Code Signing
    
    CertContext[0][2]: dwInfoStatus=10c dwErrorStatus=0
      Issuer: CN=UTN-USERFirst-Object, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, S=UT, C=US
      NotBefore: 1999-07-09 21:31
      NotAfter: 2019-07-09 21:40
      Subject: CN=UTN-USERFirst-Object, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, S=UT, C=US
      Serial: 44be0c8b500024b411d3362de0b35f1b
      e1 2d fb 4b 41 d7 d9 c3 2b 30 51 4b ac 1d 81 d8 38 5e 2d 46
      Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
      Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
      Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
      ----------------  Certificate AIA  ----------------
      No URLs "None" Time: 0
      ----------------  Certificate CDP  ----------------
      Verified "Base CRL (3898)" Time: 0
        [0.0] http://crl.usertrust.com/UTN-USERFirst-Object.crl
    
      ----------------  Base CRL CDP  ----------------
      No URLs "None" Time: 0
      ----------------  Certificate OCSP  ----------------
      No URLs "None" Time: 0
      --------------------------------
        CRL 3898:
        Issuer: CN=UTN-USERFirst-Object, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, S=UT, C=US
        4f 4f fc 29 44 da af fb 6e 2c ca ad d5 d7 0f 25 84 83 7d 56
      Application[0] = 1.3.6.1.5.5.7.3.3 Code Signing
      Application[1] = 1.3.6.1.5.5.7.3.8 Time Stamping
      Application[2] = 1.3.6.1.4.1.311.10.3.4 Encrypting File System
    
    Exclude leaf cert:
      98 57 22 49 05 0a f8 ba e2 42 6b ac 06 f3 83 98 59 85 c5 95
    Full chain:
      db ea 02 f6 eb b3 0e f4 99 67 75 58 d5 ca 48 dc 88 95 cc f7
    ------------------------------------
    Verified Issuance Policies:
        1.3.6.1.4.1.6449.1.2.1.3.2
    Verified Application Policies:
        1.3.6.1.5.5.7.3.3 Code Signing
    Cert is an End Entity certificate
    Leaf certificate revocation check passed
    CertUtil: -verify command completed successfully.
    

    All http-s are accessible.


    • Edited by GunSmoker Tuesday, December 16, 2014 12:40 PM
    Tuesday, December 16, 2014 12:39 PM
  • Pavel, no - these are two separate non-related people/machines.
    Tuesday, December 16, 2014 12:41 PM
  • Hi,

    To check if the trust-chain is ok, I suppose you double-clicked on the code signing certificate and checked the Certification Path tab to see if all the chain is ok and visible (I suppose there is a Comodo Root CA, a Code Signing Sub-CA and the user certificate).

    However, as a check, open che Local Machine certificate store and Current User certificate store through the MMC Certificate snapshot, and check that Comodo RootCA is only inside the Trusted Root Certification Authorities and only one time ( not in the other stores) and that. if your code signing certificate has one, the Comodo SubCA is only inside Intermediate Certification Authority and only one time (not in user stores). Usually if you put CA certificates inside Local Computer store, they will be visible in Current User also, so I put them only on Local Computer if possible. 

    Another good check is to see if the SubCA revocation passes (in your certutil -verify you are checking only the "leaf certificate revocation"), use the same command on the SubCA also if one exists.


    DieguZ

    Tuesday, December 16, 2014 12:57 PM
  • We found the reason for this.

    It is indeed a problem with Malwarebytes tool. Its driver (mbamchameleon.sys) injects into CreateProcess call and cause infinite loop during check for digital signature of some signed executables.

    https://support.eurekalog.com/index.php?/Knowledgebase/Article/View/67/4/installer-hangs-on-launch

    • Marked as answer by GunSmoker Tuesday, February 10, 2015 4:40 PM
    Tuesday, February 10, 2015 4:40 PM