6.2. What’s Fixed in 7.1.0
6.2.1. Fixes Related to Discovery and Authentication
6.2.1.1. Rare ‘copy failure’ error while getting participant details before Discovery completed
If you called the API function get_discovered_participant_data() or get_discovered_participant_subject_name() on a DomainParticipant while it was in the process of discovering other DomainParticipants or their endpoints, then in rare cases, the DomainParticipant failed to discover other DomainParticipants or their endpoints. An accompanying error message referred to PRESParticipant_onSecurityChannelWriteEvent or PRESParticipant_processMatchedRemoteEndpointSecurity and a failure to copy a remoteParticipant table.
This problem, which might have prevented communication between the two involved DomainParticipants for one or more of their Topics, has been fixed. This error message will no longer occur, and discovery will no longer fail due to this error message.
[RTI Issue ID SEC-1779]
6.2.1.2. Missing security information in the Participant Builtin Topic data
Connext 7.0.0 introduced relevant security information as part of the DomainParticipant’s builtin topic data. The 7.0.0 release added two new fields: trust_algorithms (renamed in 7.1.0 to trust_algorithm_info) and trust_info (renamed in 7.1.0 to trust_protection_info). In 7.0.0, you were able to retrieve this information using the discovered_participant_data() API.
The security information should also have been available through the samples of the DomainParticipant’s builtin Subscriber. This was not the case in Connext 7.0.0.
This problem has been resolved. Now you can get the DomainParticipant’s builtin Topic data using the on_data_available() callbacks for its builtin Subcriber, and the trust_algorithm_info and trust_protection_info fields will be correctly populated.
[RTI Issue ID SEC-1871]
6.2.1.3. Unbounded memory growth and ‘deadlock risk’ error when deleting a DataWriter matched with a DataReader on same DomainParticipant
This problem applied to DataWriters that were created with a Governance Document whose metadata_protection_kind or data_protection_kind for the DataWriter’s topic was a value other than NONE.
If you deleted a DataWriter matched with a DataReader on the same DomainParticipant, and the PublisherQos of the DataWriter’sPublisher did not have exclusive_area.use_shared_exclusive_area set to true, it was possible to see a ‘deadlock risk’ error about failing to enter level 20 from level 30. This error indicated a failure to free memory, and continuing to create and delete DataWriters could have led to unbounded memory growth. This problem was more likely to occur if the DataWriter and DataReader had compatible types and matching topics, but had some other kind of incompatibility. This problem has been resolved.
[RTI Issue ID SEC-1883]
6.2.2. Fixes Related to Cryptography
6.2.2.1. Session keys renewed half as frequently as they should have been
The Security Plugins update the session keys after protecting some message blocks. The cryptography.max_blocks_per_session property determines how many message blocks can be encrypted using the same session key.
However, the cryptography.max_blocks_per_session’s effective value depended on the cryptography.encryption_algorithm property. In the case of AES256+GCM, the effective value was double the property value. In the case of AES192+GCM, the effective value was 1.5 times the property value. The issue did not affect AES128+GCM. This problem occurred for all protection types. See Session keys were not renewed as often as they should when using RTPS SIGN protection for further overuse of session keys affecting only RTPS SIGN protection.
The issue has been fixed.
[RTI Issue ID SEC-1231]
6.2.2.2. data_protection_kind = SIGN was sometimes treated as ENCRYPT
For a given topic, if the Governance Document tag data_protection_kind had a value of SIGN and either of the following conditions was true, the serialized payload was mistakenly encrypted:
The Governance Document tag metadata_protection_kind had a value of ENCRYPT.
metadata_protection_kind had a value of SIGN and the DomainParticipant’s PropertyQosPolicy cryptography.share_key_for_metadata_and_data_protection had a value of FALSE.
This problem has been fixed. The serialized payload is now unencrypted (protected with AES-GMAC) in the above scenarios.
[RTI Issue ID SEC-1773]
6.2.2.3. Possible crash when disable_endpoint_security_info_propagation was true
A DataReader may have crashed due to a race condition when the following conditions were met:
dds.participant.discovery_config.disable_endpoint_security_info_propagation was set to true (see the RTI Connext Migration Guide).
A DataReader’s DomainParticipant’s Governance Document had metadata_protection_kind set to NONE
A matched DataWriter’s DomainParticipant’s Governance Document had metadata_protection_kind set to something other than NONE (which is a configuration allowed by this version of Connext but that is not compliant with OMG DDS Security specification, and therefore discouraged).
A memory checking tool such as Valgrind™ would have reported invalid reads in a function due to accessing an address freed by a different function. This problem has been fixed.
[RTI Issue ID SEC-1747]
6.2.2.4. Session keys were not renewed as often as they should when using RTPS SIGN protection
The Security Plugins update the session keys after protecting some message blocks. The cryptography.max_blocks_per_session property determines how many message blocks can be encrypted using the same session key.
However, cryptography.max_blocks_per_session had an effective value larger than the property value when using RTPS SIGN (or SIGN_WITH_ORIGIN_AUTHENTICATION) protection. The problem led to slightly overused session keys in some scenarios. This issue only affected Security Plugins 7.0.0 and has been fixed.
[RTI Issue ID SEC-1786]
6.2.2.5. Value AES192+GCM for cryptography.encryption_algorithm did not work
Connext 7.0.0 introduced the following values for the cryptography.encryption_algorithm property: AES128+GCM, AES192+GCM, and AES256+GCM. These new values are meant to replace but still coexist with the legacy ones: aes-128-gcm, aes-192-gcm, and aes-256-gcm.
However, the AES192+GCM choice did not work correctly. The workaround for setting the AES-192 symmetric cipher algorithm was to use the aes-192-gcm legacy value. This issue has been fixed.
[RTI Issue ID SEC-1806]
6.2.2.6. Setting wrong value for symmetric cipher algorithm failed silently
In release 7.0.0, configuring the cryptography.encryption_algorithm property with a wrong value failed silently. In these cases, the final value of the property was AES256+GCM (the default). This problem has been resolved. Now if the property is set to a wrong value, there will be a failure during DomainParticipant creation.
[RTI Issue ID SEC-1807]
6.2.2.7. Race conditions related to banish_ignored_participants may have caused crashes or decoding errors
The banish_ignored_participants() API (introduced in Security Plugins 7.0.0) had several concurrency problems that led to potential crashes or decoding errors. These problems may have occurred during deletion of a local DataWriter or DataReader, or when a DataWriter’s key material for Submessage Protection was different from its key material for Serialized Data Protection (see share key for metadata and data protection, in Design Considerations, in the Security Plugins User’s Manual).
These problems have been resolved.
[RTI Issue ID SEC-1825]
6.2.2.8. Communication failure when using origin authentication and banish_ignored_participants
If you set the Governance document tag rtps_protection_kind or metadata_protection_kind to SIGN_WITH_ORIGIN_AUTHENTICATION or ENCRYPT_WITH_ORIGIN_AUTHENTICATION, and you successfully called the API banish_ignored_participants(), you would have experienced a persistent communication failure. This failure was accompanied by this error message:
RTI_Security_Cryptography_verifyReceiverSpecificMac:
OpenSSL function EVP_DecryptFinal_ex (GMAC) failed with error:
(error details not available).
This problem has been resolved.
[RTI Issue ID SEC-1862]
6.2.2.9. Communication failure when using origin authentication and max_blocks_per_session
If you set the Governance document tag rtps_protection_kind or metadata_protection_kind to SIGN_WITH_ORIGIN_AUTHENTICATION or ENCRYPT_WITH_ORIGIN_AUTHENTICATION, you would have experienced a persistent communication failure when the Session Keys were changed due to the property cryptography.max_blocks_per_session (see Limiting the Usage of a Specific Session Key, in the Security Plugins User’s Manual). This failure was accompanied by an error message such as:
DecryptFinal failed. Possible GCM authentication failure
This problem has been resolved.
[RTI Issue ID SEC-1863]
6.2.2.10. Potential invalid read while decoding encrypted messages
In previous releases, receiving a malformed, protected RTPS message may have resulted in invalid memory reads or, in very rare crashes, in a crash. This issue, which did not impact the confidentiality or integrity of Connext applications, has been fixed
[RTI Issue ID SEC-1892]
6.2.3. Fixes Related to Reliability Protocol and Wire Representation
6.2.3.1. Unexpected error ‘Fragment data not supported by this writer’
In Connext 7.0.0, you may have seen the following error when trying to run an application that had set the dds.participant.protocol.rtps_overhead property and it was using the Security Plugins. The same configuration did not fail in previous releases.
{noformat}ERROR COMMENDFacade_canSampleBeSent:NOT SUPPORTED | Fragment data not supported by this writer.{noformat}
To workaround the issue, you could have removed the property dds.participant.protocol.rtps_overhead from the Participant’s configuration. This is also the recommended configuration starting with 7.0.0, as the overhead is automatically calculated by the middleware. This problem has been resolved.
[RTI Issue ID SEC-1813]
6.2.4. Fixes Related to Entities
6.2.4.1. Error creating participant with specific local GUID prefixes using security
An error occurred if a participant had a hostId, appId, or instanceId set to zero.
[RTI Issue ID SEC-1835]
6.2.5. Fixes Related to Shipped Examples
6.2.5.1. DomainParticipantQoS in C hello_security was not finalized
When using static libraries in the C hello_security example, the DomainParticipantQoS was not being finalized. This caused memory leaks for the QoS. This issue has been fixed by properly finalizing the DomainParticipantQoS at the end of execution.
[RTI Issue ID SEC-1699]
6.2.6. Fixes Related to Vulnerabilities
6.2.6.1. Submessage Protection was ineffective at protecting against submessage tampering
Submessage Protection was ineffective at protecting against submessage tampering. This problem has been resolved.
A vulnerability in the Connext application could have resulted in the following:
An attacker was able to bypass Submessage Protection authentication (enabled with metadata_protection_kind set to SIGN, ENCRYPT, SIGN_WITH_ORIGIN_AUTHENTICATION, or ENCRYPT_WITH_ORIGIN_AUTHENTICATION) and inject untrusted submessages to the system.
Still, an attacker was not able bypass Submessage Protection encryption (enabled with metadata_protection_kind set to ENCRYPT or ENCRYPT_WITH_ORIGIN_AUTHENTICATION) to read protected submessages.
Remotely exploitable only if rtps_protection_kind was set to NONE or if a trusted Domain Participant was already compromised by a previous attack.
Potential impact on integrity of Connext application.
CVSS Base Score: 9.1 CRITICAL
CVSS v3.1 Vector: AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H
Note that this vulnerability is only fixed as long as the (now deprecated and discouraged to be used) participant’s property disable_endpoint_security_info_propagation is set to FALSE, which is the default value.
[RTI Issue ID SEC-1887]
6.2.6.2. Potential Denial of Service when using OpenSSL 1.1.1 due to a vulnerability in OpenSSL 1.1.1
The Security Plugins had a third-party dependency on OpenSSL 1.1.1, which is known to be affected by a number of publicly disclosed vulnerabilities. These vulnerabilities have been fixed by upgrading OpenSSL to the latest stable version, 1.1.1t.
User Impact without Security: No impact.
User Impact with Security: The impact to Security Plugins applications when using the previous version was as follows:
Exploitable by triggering the parsing of malicious certificates that need to be checked against a CRL obtained from a CRL distribution point.
The application could hang.
CVSS Base Score: 7.5 HIGH
CVSS v3.1 Vector: AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
This issue has been fixed.
[RTI Issue ID SEC-1955 THIRDPARTY-70]
6.2.6.3. Authentication handshake did not effectively protect against GUID impersonation
The authentication handshake was ineffective at protecting against GUID impersonation. This problem has been resolved.
User Impact without Security: No impact. This issue is only applicable when using Security.
User Impact with Security: A vulnerability in the Connext application could have allowed an attacker to bypass any user-level dynamic access control built around GUIDs. As a result, other DomainParticipants would have accepted an attacker using the wrong GUID. The user impact was as follows:
Remotely exploitable
Potential impact on integrity of Connext application
CVSS Base Score: 9.8 CRITICAL
CVSS v3.1 Vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
[RTI Issue ID SEC-1988]
6.2.7. Fixes Related to Security Plugins SDK
6.2.7.1. Instructions on statically building Security Plugins SDK referred to the wrong cmake version
In release 6.1.1, the Security Plugins SDK introduced a buildable test suite, which allows you to validate the Security Plugins source code. In order to build the test suite statically (-DBUILD_SHARED_LIBS=OFF), a cmake version of at least 3.13 is required.
However, the documentation previously stated that the minimum cmake version was 3.12. This documentation issue is now fixed. The requirements now specify that if you are compiling the SDK statically, the minimum cmake version is 3.13.
[RTI Issue ID SEC-1884]
6.2.8. Fixes Related to Crashes
6.2.8.1. Potential crash while decoding protected submessages
Release 6.1.1 introduced several performance optimizations to Submessage Protection decoding. There was an issue with one of these optimizations, potentially resulting in a rare crash on the receiver (DataWriter or DataReader) while decoding a protected submessage.
In particular, this issue was triggerable if any of the following were true for at least one DataWriter/DataReader pair:
metadata_protection_kind set to a value different from NONE
discovery_protection_kind set to a value different from NONE and enable_discovery_protection is TRUE
liveliness_protection_kind set to a value different from NONE and enable_liveliness_protection is TRUE
This issue was more likely to trigger when the sender’s DomainParticipant was deleting all of its endpoints. This issue has been fixed; decoding protected submessages no longer results in a crash.
[RTI Issue ID SEC-1960]