6.4. What’s Fixed in 7.1.0

[Critical]: System-stopping issue, such as a crash or data loss.
[Major]: Significant issue with no easy workaround.
[Minor]: Issue that usually has a workaround.
[Trivial]: Small issue, such as a typo in a log.

6.4.1. Fixes Related to Discovery and Authentication

6.4.1.1. [Critical] 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.4.1.2. [Critical] 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.4.1.3. [Minor] 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.4.2. Fixes Related to Cryptography

6.4.2.1. [Critical] 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 cases, in a crash. This issue, which did not affect the confidentiality or integrity of Connext applications, has been fixed.

[RTI Issue ID SEC-1892]

6.4.2.2. [Critical] 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 RTI 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.4.2.3. [Critical] 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.4.2.5. [Critical] 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 the 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.4.2.6. [Major] 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 [Major] 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.4.2.7. [Major] 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.4.2.8. [Major] 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.4.2.9. [Minor] 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.4.2.10. [Trivial] 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.4.6. Fixes Related to Vulnerabilities

6.4.6.1. [Critical] 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.4.6.2. [Critical] 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.4.6.3. [Critical] 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.4. What’s Fixed in 7.1.0

6.4.1. Fixes Related to Discovery and Authentication

6.4.1.1. [Critical] Rare ‘copy failure’ error while getting participant details before Discovery completed

6.4.1.2. [Critical] Unbounded memory growth and ‘deadlock risk’ error when deleting a DataWriter matched with a DataReader on same DomainParticipant

6.4.1.3. [Minor] Missing security information in the Participant Builtin Topic data *

6.4.2. Fixes Related to Cryptography

6.4.2.1. [Critical] Potential invalid read while decoding encrypted messages

6.4.2.2. [Critical] Communication failure when using origin authentication and max_blocks_per_session

6.4.2.3. [Critical] Communication failure when using origin authentication and banish_ignored_participants *

6.4.2.4. [Critical] Race conditions related to banish_ignored_participants may have caused crashes or decoding errors *

6.4.2.5. [Critical] Possible crash when disable_endpoint_security_info_propagation was true

6.4.2.6. [Major] Session keys renewed half as frequently as they should have been

6.4.2.7. [Major] data_protection_kind = SIGN was sometimes treated as ENCRYPT

6.4.2.8. [Major] Session keys were not renewed as often as they should when using RTPS SIGN protection *

6.4.2.9. [Minor] Value AES192+GCM for cryptography.encryption_algorithm did not work *

6.4.2.10. [Trivial] Setting wrong value for symmetric cipher algorithm failed silently *

6.4.3. Fixes Related to Reliability Protocol and Wire Representation

6.4.3.1. [Minor] Unexpected error ‘Fragment data not supported by this writer’ *

6.4.4. Fixes Related to Entities

6.4.4.1. [Major] Error creating participant with specific local GUID prefixes using security

6.4.5. Fixes Related to Shipped Examples

6.4.5.1. [Trivial] DomainParticipantQoS in C hello_security was not finalized

6.4.6. Fixes Related to Vulnerabilities

6.4.6.1. [Critical] Submessage Protection was ineffective at protecting against submessage tampering

6.4.6.2. [Critical] Potential Denial of Service when using OpenSSL 1.1.1 due to a vulnerability in OpenSSL 1.1.1

6.4.6.3. [Critical] Authentication handshake did not effectively protect against GUID impersonation

6.4.7. Fixes Related to Security Plugins SDK

6.4.7.1. [Minor] Instructions on statically building Security Plugins SDK referred to the wrong cmake version

6.4.8. Fixes Related to Crashes

6.4.8.1. [Critical] Potential crash while decoding protected submessages