Jump to content

Beech Horn

Members
  • Posts

    13
  • Joined

  • Last visited

About Beech Horn

  • Rank
    Newbie
    Newbie

Profile Information

  • Location
    U.K.
  1. Even the latest service pack contains the same rll file. Disabling automatic exclusions makes no difference.
  2. If it's 100% that and there's no conflict where SQL Client's use by one application is blocked due to ESET running as a Protected Service then great, I can take it back to the development team on their side.
  3. Am seeing fewer entries in event viewer having toggled that option off, but we still have the blocking behavior to our application with Protected Service turned on. For reference, the application is Sage X3. We have to run with Protected Service turned off for it to function correctly.
  4. That line looks like the example from: https://docs.microsoft.com/en-us/previous-versions/windows/hardware/code-signing/dn756632(v=vs.85)#user-mode-and-kernel-mode-code-troubleshooting With the signing levels being: 0x0: Unchecked 0x1: Unsigned 0x2: Enterprise 0x3: Custom 1 0x4: Authenticode 0x5: Custom 2 0x6: Store 0x7: Custom 3 / Antimalware 0x8: Microsoft 0x9: Custom 4 0xa: Custom 5 0xb: Dynamic Code Generation 0xc: Windows 0xd: Windows Protected Process Light 0xe: Windows TCB 0xf: Custom 6 It looks like you are requesting all DLLs to be higher than (or more likely equal to) 0x7 (Antimalware) and this DLL is actually 0x1 (Unsigned). THE FOLLOWING IS THEORY AND SHOULD NOT BE CONSIDERED ACCURATE To me, it looks like NOD32 is loading the DLLs into its own service when running as a Protected Service rather than scanning them without loading it into memory in a manner unlike a library (e.g. without running the code or injecting the DLL into the service). On top of this sqlnclir11.rll should be reported as 0x8 instead of 0x1 by Microsoft, which is in itself a problem. If we look at 0x4 (Authenticode) this would also trigger that error but could be legitimate signed code which gets blocked due to the way NOD32 is scanning when running as a Protected Service.
  5. Completely agree. But sqlnclir11.rll isn't part of your Anti-Malware services and this is the file in question. Protected Service is used to protect ESET NOD32 itself.
  6. However that article describes the code of the anti-malware software itself. Here you are scanning a library outside of the anti-malware software.
  7. This answer on StackOverflow explains it well: https://stackoverflow.com/a/3428386/179454 So it appears to be a bug in the logic of NOD32.
  8. Microsoft's official advice is to use SignTool.exe which also shows it as being valid: https://docs.microsoft.com/en-us/windows/desktop/seccrypto/using-signtool-to-verify-a-file-signature
  9. Yes, can see that option however was looking to have that enabled. Asking some software developers they say that only the root certificate should be looked for in terms of expiry. Also that you should check the immediate certificate was valid at the time the timestamp was generated. So using that logic the rll file has been correctly digitally signed and is still valid. They suggested using the DigiCert tool on: https://www.sslsupportdesk.com/how-to-verify-a-digital-code-signing-signature-in-windows/ to make sure the rll is valid, which it shows it is. Are ESET 100% certain this isn't a bug with someone using the logic of website certificates for code signing instead of looking at the nuances?
  10. Using Edit Rules I couldn't see an option for Protected Service. Should I add it under "HIPS" > "Advanced Setup" > "Drivers always allowed to load"?
  11. You may wish to warn those enabling HIPS on their system who have "Microsoft SQL Server 2012 Native Client" installed that there is a conflict with Protected Service as it is commonly used.
  12. So it looks like sqlnclir11.rll is signed, but the certificate expired in 2013. Even the latest version released on 19th January 2018: https://www.microsoft.com/en-us/download/details.aspx?id=50402 has the same sqlnclir11.rll file signed with the same expired certificate. As Microsoft SQL Server is a fairly common application, Microsoft seems to be in no hurry to update the signing of this file, this causes a lot of problems with our applications and we'd quite like everything else to protected as best as possible, please can we have a workaround for Protected Service and this one file?
×
×
  • Create New...