Jump to content

EFS 7.0.12014.0 - MSSQL ERROR


Recommended Posts

Hi All,

I am getting windows server 2016 event log error as "SQL Server Native Client 11.0: Unable to load sqlnclir11.rll due to either missing file or version mismatch. The application cannot continue." after update from ESET File Security 6 to 7.

Environment as :

Windows Server 2016

EFS 7.0.12014.0

MSSQL Server 2014

Any one have a solutions for this?

 

Thanks.

EFS 7 SQL Error.PNG

Link to comment
Share on other sites

  • 2 weeks later...

yes same errors  since 24.september , LOTS OF THEM ... and unable to start SQL Server agent

Log Name:      Application
Source:        SQLNCLI11.1
Date:          24.9.2018 0:11:45
Event ID:      1
Task Category: None
Level:         Error
Keywords:      Classic

Description:
SQL Server Native Client 11.0: Unable to load sqlnclir11.rll due to either missing file or version mismatch. The application cannot continue.
Event Xml:

EFS 7.0.12014.0

Windows Server 2012 R2

SQL Server 2014


 

Edited by gabrielk
Link to comment
Share on other sites

  • 2 weeks later...

We are experiencing the same problem on servers when upgrading from ESET EFSW 6.5.x to 7.0.12016.0. This happens on all servers with SQL installed. Has occurred with SQL 2012, 2014, and 2016. Running a repair of the SQL native Client does not fix the problem. The only fix we found, and not a good one, is if there is a SQL service pack upgrade available, installing that fixes the problem. 

Errors in event log every half hour - SQL Server Native Client 11.0: Unable to load sqlnclir11.rll due to either missing file or version mismatch. The application cannot continue.

Hopefully ESET will figure this out and implement a fix. Meanwhile we are not pushing out any more upgrades to v7.x on servers. 

Edited by P-Allen
Incorrect version noted
Link to comment
Share on other sites

  • Administrators

The problem is the dll C:\Windows\System32\1033\sqlnclir11.rll is not properly signed. Since ekrn works as a protected service, only properly signed dlls can be loaded in the protected process.

If you don't observe any other issues caused by this, please ignore the error. Should it cause any issues, temporarily disable protected service in the HIPS setup and reboot the machine until Microsoft addresses the issue by properly signing the dll.

Link to comment
Share on other sites

Well , it's hard to ignore these errors when there are tons of them flooding the event logs. 

After applying the  SQL Server 2014 Service Pack 3 (KB4022619) the problem is gone i.e. FIXED

Download size: 791,1 MB

You may need to restart your computer for this update to take effect.

Update type: Optional

Service Pack 3 for SQL Server 2014 upgraded all SQL Server 2014 instances and components installed through the SQL Server setup.  Service Pack 3 can upgrade all editions of SQL Server 2014 to Service Pack 3 level. For customers in need of additional installation options, please visit the Microsoft Download Center and download the Service Pack 3 SQL Server 2014. To learn more about SQL Server 2014 SP3 please visit the Microsoft Support (hxxp://support.microsoft.com) Knowledge Base article KB 4022619.

More information: 
hxxp://support.microsoft.com/kb/4022619

Link to comment
Share on other sites

Hi

Unable to install the Service Pack as I have the issue on SQL Server 2016...

Marcos, the issue occurs since version 7.0 and not with 6.5, there was a change in ESET that made this dll signing issue visible ?

Thanks

Link to comment
Share on other sites

  • Administrators

Support for protected service was first added in EFSW v7. With protected service enabled, only dlls with a valid signature can be loaded in protected processes.

Link to comment
Share on other sites

  • 4 weeks later...

I am also seeing this error on a Windows Server with MS SQL Server 2012 Express LocalDB (ver. 11.4.7469.6) and MS SQL Server 2012 Native Client (ver. 11.4.7001.0) that were installed with MS Azure AD Connect ver. 1.1.888.0.

On 12/12/2018 at 10:40 AM, Marcos said:

The problem is the dll C:\Windows\System32\1033\sqlnclir11.rll is not properly signed. Since ekrn works as a protected service, only properly signed dlls can be loaded in the protected process.

If you don't observe any other issues caused by this, please ignore the error. Should it cause any issues, temporarily disable protected service in the HIPS setup and reboot the machine until Microsoft addresses the issue by properly signing the dll.

BTW, sqlnclir11.rll is not a DLL but a RLL file explained here:
https://docs.microsoft.com/en-us/sql/relational-databases/native-client/applications/components-of-sql-server-native-client

I do not understand why ekrn service, that works as a protected service, needs to load sqlnclir11.rll file.

Edited by rpremuz
clarification
Link to comment
Share on other sites

  • 3 weeks later...
On 12/18/2018 at 6:25 AM, Marcos said:

Support for protected service was first added in EFSW v7. With protected service enabled, only dlls with a valid signature can be loaded in protected processes.

What's the workaround on this? It's causing client software crashes in one of our environments. Uninstalling ESET off of the server got rid of the above mentioned error and the frequent disconnects. Can we whitelist this process somehow?

Link to comment
Share on other sites

  • 2 weeks later...

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?

Link to comment
Share on other sites

  • Administrators
2 minutes ago, Beech Horn said:

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?

There is no way to solve it if Microsoft doesn't update the rll file with one with a valid signature except disabling Protected service in the HIPS setup which would enable unsigned dll files to be loaded in ekrn.exe. Of course, that would be a security hole and unnecessary risk so we don't recommend disabling protected service.

Link to comment
Share on other sites

1 hour ago, Marcos said:

There is no way to solve it if Microsoft doesn't update the rll file with one with a valid signature except disabling Protected service in the HIPS setup which would enable unsigned dll files to be loaded in ekrn.exe. Of course, that would be a security hole and unnecessary risk so we don't recommend disabling protected service.

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.

Link to comment
Share on other sites

  • Administrators

It is not a conflict, the system feature of protected services works as expected and it does what it's supposed to do - prevents files with invalid digital signature from being loaded into protected processes.

Link to comment
Share on other sites

  • Administrators

You could try disabling automatic exclusions and adding them manually instead. Let us know if the error is no longer reported after rebooting the server.

Link to comment
Share on other sites

7 minutes ago, Marcos said:

You could try disabling automatic exclusions and adding them manually instead. Let us know if the error is no longer reported after rebooting the server.

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

Link to comment
Share on other sites

  • Administrators

I meant this setting:

image.png

However, disabling protected service will disable an important protection service of Windows 10 and an attacker could theoretically inject into ESET's ekrn.exe running under the system account.

Link to comment
Share on other sites

13 hours ago, Marcos said:

I meant this setting:

image.png

However, disabling protected service will disable an important protection service of Windows 10 and an attacker could theoretically inject into ESET's ekrn.exe running under the system account.

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?

cert1.png

cert2.png

digicert.png

Link to comment
Share on other sites

This answer on StackOverflow explains it well:

https://stackoverflow.com/a/3428386/179454

Quote

 

Is timestamped code valid after a Code Signing Certificate expires?

  • Microsoft® Authenticode® (Multi-Purpose) allows you to timestamp your signed code. Timestamping ensures that code will not expire when the certificate expires because the browser validates the timestamp. The timestamping service is provided courtesy of VeriSign. If you use the timestamping service when signing code, a hash of your code is sent to VeriSign’s server to record a timestamp for your code. A user’s software can distinguish between code signed with an expired certificate that should not be trusted and code that was signed with a Certificate that was valid at the time the code was signed but which has subsequently expired.

 

So it appears to be a bug in the logic of NOD32.

Edited by Beech Horn
Link to comment
Share on other sites

  • Administrators

A HIPS developer responded that it's not about signing files in general, otherwise malware authors could buy one and circumvent the system of protected services implemented in Windows 10.

PS needs a properly signed dll with a signature that is expected by CI component.  A properly signed dll must meet Anti-Malware Services requirements described at https://docs.microsoft.com/en-us/windows/desktop/services/protecting-anti-malware-services- :

Anti-malware service signing requirements

The user-mode service that needs to be launched as protected must be signed with valid certificates. The service EXE must be page hash signed, and any non-Windows DLLs that get loaded into the service must be also signed with the same certificates. The hash of these certificates must be added into the resource file, which will be linked into the ELAM driver.

 

Link to comment
Share on other sites

5 minutes ago, Marcos said:

A HIPS developer responded that it's not about signing files in general, otherwise malware authors could buy one and circumvent the system of protected services implemented in Windows 10.

PS needs a properly signed dll with a signature that is expected by CI component.  A properly signed dll must meet Anti-Malware Services requirements described at https://docs.microsoft.com/en-us/windows/desktop/services/protecting-anti-malware-services- :

Anti-malware service signing requirements

The user-mode service that needs to be launched as protected must be signed with valid certificates. The service EXE must be page hash signed, and any non-Windows DLLs that get loaded into the service must be also signed with the same certificates. The hash of these certificates must be added into the resource file, which will be linked into the ELAM driver.

 

However that article describes the code of the anti-malware software itself. Here you are scanning a library outside of the anti-malware software.

Edited by Beech Horn
Link to comment
Share on other sites

2 minutes ago, Marcos said:

Protected service is a part of Anti-Malware Services protection mechanisms.

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.

Edited by Beech Horn
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...