Log In
Home
02/02/2022
Offline
We have a .net application that uses OpcNetApi from OPC foundation to communicate with remote OPC servers. When we tested our application with the Microsoft update that address the CVE-2021-26414 vulnerability we found issues and our application is not able to call the server successfully.
Is there a new version or plan to create a new version of OPCNetApi which addresses this issue?
05/30/2017
Offline
The issue is likely with your initialization of COM within the apartment that your process is using. This issue can be fixed by changing how COM apartment security is initialized in your application. You should not need an update to the NetApi (others have fixed their clients for this CVE with no issues).
02/02/2022
Offline
Thanks for the response. For OPC AE when we added a call to CoInitializeSecurity method with RpcAuthnLevel.PktIntegrity instead of RpcAuthnLevel.None from our application was able to connect to the OPC AE server without having to change anything in OPCNETApi.
But in the case of OPC DA client just adding CoInitializeSecurity method with RpcAuthnLevel.PktIntegrity instead of RpcAuthnLevel.None doesn't seem to be enough in our case. We had to make the following change to OpcNetApi.Com code:
1. In OpcCom.ServerInfo.Allocate method while initializing COAUTHINFO (to pass it to GCHandle.Alloc method) we had to change the dwAuthnLevel from RPC_C_AUTHN_LEVEL_CONNECT to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY
2. In OpcCOM.Interop.CreateInstanceWithLicenseKey method while calling IClientSecurity.SetBlanket method we had pass pAuthnLevel as RPC_C_AUTHN_LEVEL_PKT_INTEGRITY instead of RPC_C_AUTHN_LEVEL_CONNECT
If we don't make these two changes we get the following error:
Application <OurApplication.exe> with PID 2024 is requesting to activate CLSID {63482C41-5891-81A2-D416-3AE306C10000} on computer opserver1 with explicitly set authentication level at 2. The lowest activation authentication level required by DCOM is 5(RPC_C_AUTHN_LEVEL_PKT_INTEGRITY). To raise the activation authentication level, please contact the application vendor.
Can you please suggest if we are missing something here.
We also tried to change the Dcom setting on the client machine from Connect to Packet Integrity (dcomcnfg->My Computer - Default Properties -> Default Authentication level) but it didn't help.
05/30/2017
Offline
Remember that with OPC and DCOM the "Server" need connect back to the Client so the difference may be a problem with the Server initialization.
You can also remove all explicit calls to CoInitializeSecurity and rely entirely on DCOMconfig.
02/02/2022
Offline
Tried the following steps:
1. Removed the calls to CoInitializeSecurity,
2. Reverted all the changes done in OPCNetApi
3. Changed the Dcom setting on the client machine from Connect to Packet Integrity (dcomcnfg->My Computer -> Default Properties -> Default Authentication level) but it didn't help.
But the issue doesn't go away.
05/30/2017
Offline
Have you tried with different servers?
You may need to remove calls make by OPCNetApi to CoInitializeSecurity.
02/02/2022
Offline
Yes we have tried with different servers, if we don't make the above mentioned change in OPCNetApi we get the following error:
Application <OurApplication.exe> with PID 2024 is requesting to activate CLSID {63482C41-5891-81A2-D416-3AE306C10000} on computer opserver1 with explicitly set authentication level at 2. The lowest activation authentication level required by DCOM is 5(RPC_C_AUTHN_LEVEL_PKT_INTEGRITY). To raise the activation authentication level, please contact the application vendor.
OPCNetApi doesn't call CoInitializeSecurity method directly.
Are there any working sample that demonstrates that OPCNetApi works without any code changes in DCOM hardened environment? If so can you please share it.
Thanks in Advance.
05/30/2017
Offline
What puzzles me is you say it works for AE. There should not be any difference between AE and DA.
The AE client would be a working client example.
Can you create a simple .NET application that does nothing but launch the server without using the OPCNetAPI?
If that works can you use the OpcComRcw directly to launch the Server and call GetStatus?
02/02/2022
Offline
We tried with OPC DA Sample client that is available in the OPCNETApi package, that didn't work straight away. Once we make the changes mentioned above it starts working.
05/30/2017
Offline
To confirm:
The sample client works if RPC_C_AUTHN_LEVEL_PKT_INTEGRITY is set.
Your application does not work even if RPC_C_AUTHN_LEVEL_PKT_INTEGRITY is set.
Is this correct?
02/02/2022
Offline
Both sample application and our application works when we change dwAuthnLevel from RPC_C_AUTHN_LEVEL_CONNECT to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY in OpcCom.ServerInfo.Allocate method and in OpcCOM.Interop.CreateInstanceWithLicenseKey method of OpcNetApi.Com project.
We are ok to make this modification and proceed. Once we complete our testing we have to issue a patch to our customers with this modified version. Our main concern is about the license agreement, are we allowed to ship the modified version of OPCNETApi dlls with our product as it is or is there any other procedure we have to follow if we have to do that?
05/30/2017
Offline
Corporate members are free to modify an distribute but you will have to add your own strong name (the key used from the NuGet packages is not public).
I also suggest giving your versions of the DLLs different names.
I suspect other users do this already which is why others seem to have had no problems with the CVE (they just fixed without raising an issue).
02/02/2022
Offline
thanks for the details
04/15/2015
Offline
Randy,
When corporate members are modifying code to resolve the issue and distributing the new dll's with their own strong names and different names, what is the license that is still applicable? Is RCL still applicable for these components which we need to publish with our product or it is complete open source?
Thank you,
Mohammad Areef
05/30/2017
Offline
I am concerned that updating the security settings would not work for all applications.
So the recommendation effectly is that the security settings be removed from OpcNetApi code and handled in applications where the vendor is best able to ensure that the new settings work for them.
IOW, it is an exception to RCL rules because of the unique nature of DCOM security issues.
09/24/2018
Offline
Hello Randy,
do you have any information regarding incorporation of the changes you suggested into the downloadable packages?
Will there be a new version without a call to CoInitializeSecurity?
05/30/2017
Offline
I posted an RC of 109:
https://opcfoundation.org/deve.....-packages/
Can people try and tell me if it works for them.
09/04/2014
Offline
Hi Randy,
I tried with RC of 109. Still the connection to the OPC Server failing with following error in Event Log on the client machine.
Application XXX with PID XXX is requesting to activate CLSID {XXXX} on computer XXX with default activation authentication level at 2. The lowest activation authentication level required by DCOM is 5(RPC_C_AUTHN_LEVEL_PKT_INTEGRITY). To raise the activation authentication level, please contact the application vendor.
I tried to debug and noticed that line number 445 ServerInfo.Allocate in \NET API\COM Wrapper\OpcCom.Interop.cs is setting authInfo.dwAuthnLevel = RPC_C_AUTHN_LEVEL_CONNECT;
This method is getting called when we try to Connect to OPC Server with ConnectData parameter.
Can this method be updated to use RPC_C_AUTHN_LEVEL_PKT_INTEGRITY?
Regards,
Vijay
05/30/2017
Offline
109 is supposed to use RPC_C_AUTHN_LEVEL_PKT_INTEGRITY.
Can you confirm you loaded the correct assembly?
The code I expect:
// create authorization info structure.
COAUTHINFO authInfo = new COAUTHINFO();authInfo.dwAuthnSvc = RPC_C_AUTHN_WINNT;
authInfo.dwAuthzSvc = RPC_C_AUTHZ_NONE;
authInfo.pwszServerPrincName = IntPtr.Zero;
authInfo.dwAuthnLevel = (useConnectSecurity) ? RPC_C_AUTHN_LEVEL_CONNECT : RPC_C_AUTHN_LEVEL_PKT_INTEGRITY;
authInfo.dwImpersonationLevel = RPC_C_IMP_LEVEL_IMPERSONATE;
authInfo.pAuthIdentityData = m_hIdentity.AddrOfPinnedObject();
authInfo.dwCapabilities = EOAC_NONE; // EOAC_DYNAMIC_CLOAKING;
09/04/2014
Offline
Randy,
I could notice following places in the code base we are trying to create COAUTHINFO
1) \Common\NetRcw\Utils.cs Line Number 446 : public COSERVERINFO Allocate(string hostName, string username, string password, string domain, bool useConnectSecurity = false)
In this function as you mentioned RPC_C_AUTHN_LEVEL_PKT_INTEGRITY is getting applied based on the flag useConnectSecurity
2) \NET API\COM Wrapper\OpcCom.Interop.cs 471 : public COSERVERINFO Allocate(string hostName, NetworkCredential credential)
But in this function still I could see following code
COAUTHINFO authInfo = new COAUTHINFO();
authInfo.dwAuthnSvc = RPC_C_AUTHN_WINNT;
authInfo.dwAuthzSvc = RPC_C_AUTHZ_NONE;
authInfo.pwszServerPrincName = IntPtr.Zero;
authInfo.dwAuthnLevel = RPC_C_AUTHN_LEVEL_CONNECT;
authInfo.dwImpersonationLevel = RPC_C_IMP_LEVEL_IMPERSONATE;
authInfo.pAuthIdentityData = (m_hIdentity.IsAllocated)?m_hIdentity.AddrOfPinnedObject():IntPtr.Zero;
authInfo.dwCapabilities = EOAC_NONE;
This function is getting called when we try to connect to a opc instance.
Hope this helps
Regards,
Vijay
1 Guest(s)
Usage Policy