Possible vulnerability via memory leak under very special conditions

[SvenPC]

Hi,

On site we have had the special case that a C++ SDK based OPCUA server crashes every 4 days because no more memory was available.
We have identified an trusted OPCUA client which requests sessions with wrong credentials with a very high frequency (every 40 ms).

We have try to catch it via special tests and got an idea of the root cause. It looks like that:
- every CreateSeession allocates memory (in OS and in OPCUA SDK)
- in case of rejected session (e.g. caused by wrong credentials) some memory are freed delayed by a "cleaner task"
- but when the "cleaner task" gets no chance to do it's job it looks like a memory leak

We are not sure if it is inside
- OPCUA SDK or
- simply the mechanisms for sockets inside OS (vxWorks).

A alternative summary could be "memory leak by session flooding from trusted client".

The workaround is
- to stop the OPCUA client or
- simply reduce the frequency to ask for an session in case of rejection.

Any ideas or suggestions?

Once again: We are not really sure if it is a vulnerability of OPCUA SDK!

Thanks and regards,
Sven

[Support Team]

Hi,

As a general note:

Code: Select all

If you trust a rogue client you may get many more "security issues" than you may think. 
Whenever trusting a client you should check if it is properly programed, certified and behaves nicely.

If you give the key of your house to the cleaning personnel, they may not steal your furnature, but they could easily damage from inside.

That said i can not see any "security vulnerability" here, however in any case the OPC Server should not crash, even when being accessed by a poorly programmed client.

The SDK has many possibilities to limit the memory used, however must be configured correctly by the implementer (you), because we don't know how much memory is available on your target system. There are parameters for "MaxSecureChannels", "SessionsPerChannel", "SubscriptionsPerSession", and "ItemsPerSubscription". Some of these parameters can be set to "0" (unlimited), and it works quite fine if you have "unlimited" memory. If you have not, you better configure correctly (according to your resources).

That said, there seems to be some wrong configuration in your server.

See documentation here:
https://documentation.unified-automation.com/uasdkcpp/1.8.2/html/L2ServerSdkServerConfig.html#server_config_xml_file_serversettings

In addition to that, the OPC UA does not prevents you from (in fact encourages you to) taking even more precautions, IP-Address filter, Firewall, etc.

[SvenPC]

Thank you for the quick answer.

There is no chance to limit anything via MaxSecureChannels", "SessionsPerChannel", "SubscriptionsPerSession", "ItemsPerSubscription" or other.
The session gets rejected by the OPCUA server (e.g. via wrong username and or password or bad certificate).
With your words, the cleaning personnel has no valid key.
But it is asking very high frequently to come in.
And this end up in a memory consumption issue where OPCUA tasks gets suspended because memory allocating will fails.
For me it smells like a vulnerability. And possibly this could be used for a DoS attack?

We have had some discussions about it in our team:
- One solution might be filter rules, firewalls or something else outside of OPCUA SDK.
- Another solution could be inside OPCUA SDK: When a special IP address ask high frequently the SDK may reject the socket for while.
Is there any code / configuration built in SDK?

Thanks in advance,
Sven

[Support Team]

Hi,

I think we generally agree that "any" memory leak that untimately creates a crash is a potential DoS. However from a security vulnerability standpoint we focus on the "pre-authenticated", before being trusted. That said the server should not crash (and not have any memory leaks).

Question was where to locate the bug? In "ActivateSession" because you brute force in 40ms with wrong pwd? Here you could think about "delay" when detecting wrong pwd. Or in "CreateSession" the maximum number per client is limited to not exhaust the system resources (if configured correctly, which is a common mis configuration). In the latest version of the SDK we have implemented some (more or less) sophisticated clean up logic, because the OPC specification got more specific on what to celan up first (if not used or not activated) in which order (e.g SecureChannels, Sessions, etc.)

From what we understand from your description, here it more looks like some error handling routine is not cleaning up memory correctly when rejecing the session, because of wrong user credentials. Unfortunately with a quick test we can not reproduce such error in the C++SDK v1.8.2

Please create ticket via support form and send server side trace, so we can better understand what is called in which order (and frequency), and reproduce the scenario in our lab.