LabVIEW
Local Security Authority LabView 2024 Q3
@Basilgeuse wrote:
I am unsure how much effort anyone here wants to put into resolving this issue, but I recently needed to package NI ElvisMX for my environment, and was running into this error at the end of installation.
The main issue is that there is no certificate associated with the .dll file in question. LSA Device Guard is a bit more strict on Windows 11, and doesn't like when unsigned modules are attempted to run.
My solution was to create my own certificate and self-sign the certificate to the .dll file. Afterwards, I imported the certificate from my personal store, to the Trusted Publishers store.
After running a test installation and verifying the error no longer appears, I exported the signed certificate, added it to my package in Intune, and just wrote out a script that installs the certificate to the local machine in the trusted publishers store before installing the application.
Aside from NI properly signing all their DLLs, this is the solution that will fix it for sure for the very zealous virus scanners. Unfortunately that is not enough for kernel device drivers. Microsoft not only wants them to be signed, but they have to be signed with an Extended Verification certificate, send in to their developer center to have them counter signed with the Microsoft Certificate and only then will Windows consider the device driver a valid binary.
@Darren wrote:
This issue has already been reported to NI R&D as Bug 367869.
For now, the workaround is to delete the DLL. Your NI software should still function properly without it.
Darren, can you please update us as soon as you know anything about when it will be fixed?
(We too, have customers all over the world who are updating their Windows and we are starting to see this. And booting into safe mode is a big hassle for many of them)
@rolfk wrote:
@Basilgeuse wrote:
I am unsure how much effort anyone here wants to put into resolving this issue, but I recently needed to package NI ElvisMX for my environment, and was running into this error at the end of installation.
The main issue is that there is no certificate associated with the .dll file in question. LSA Device Guard is a bit more strict on Windows 11, and doesn't like when unsigned modules are attempted to run.
My solution was to create my own certificate and self-sign the certificate to the .dll file. Afterwards, I imported the certificate from my personal store, to the Trusted Publishers store.
After running a test installation and verifying the error no longer appears, I exported the signed certificate, added it to my package in Intune, and just wrote out a script that installs the certificate to the local machine in the trusted publishers store before installing the application.Aside from NI properly signing all their DLLs, this is the solution that will fix it for sure for the very zealous virus scanners. Unfortunately that is not enough for kernel device drivers. Microsoft not only wants them to be signed, but they have to be signed with an Extended Verification certificate, send in to their developer center to have them counter signed with the Microsoft Certificate and only then will Windows consider the device driver a valid binary.
Please explain for one who don't know too much about certificates: Is it a possible workaround to create a certificate and do the steps Basilgeuse says to fix the issue for nimdnsnsp.dll? If so, to me it sounds like I will have to persuade my customers to import my certificate and promise them that it is safe. And if so, then NI might as well create such a certificate (although they wont because they will create a proper one that IS trusted, which will take some time because they need to go through Microsoft etc.), right?.
If anyone comes up with a better way than to boot into safe mode and delete the file, that works for PC's other than in your own organization, please share.
First, the certificate itself isn't safe or unsafe. But if it is installed as root certificate in a machine, anyone who has access to your private key can sign any executable file with this certificate and then pass it to that person running a computer with your certificate installed as root certificate, and the executable will be installed even if it is the most extreme backdoor troyan you can imagine.
This does require quite a few conditions though:
- Some adversary needs to get access to your private key.
- They (or you) create a malicious executable or something and sign it with your certificate and private key.
- They send that to the customer having installed your certificate as root certificate on one or more machine and get them to install this malicious file on such a computer.
The key point is: can they trust you to not loose your private key somehow or that you don't want to send them malicious files afterwards. It's simply a question if THEY can trust YOU and then install your certificate as a root certificate on their machines. That is the entire safety about signing files.
National Instruments has signing certificates that can be traced to one of the well known root certification autorieties that Windows knows about out of the box (and through Windows Update) and the according private keys, most likely safe guarded in a highly secured air gaped location. 😁
Every executable they create needs to be brought to that highly secured computer, signed and then added to the installers. For this executable that did not happen. Considering the effort it takes to sign an executable, it is not to difficult to understand that this sometimes easily can happen and until recently that was not a problem because Windows only insisted on signed executable files for kernel space binaries. But the increased security risk landscape makes OS builders require ever more stringent measures to try to get at least a minimal assurance that any executable file isn't malicious and/or hasn't been tampered with.
