What's Fixed in 7.1.0 ===================== Fixes Related to Discovery and Authentication --------------------------------------------- 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] 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] 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] Fixes Related to Cryptography ----------------------------- 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 :ref:`section-SEC-1786` for further overuse of session keys affecting only RTPS SIGN protection. The issue has been fixed. [RTI Issue ID SEC-1231] 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] 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] .. _section-SEC-1786: 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] 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] 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] 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 :link_connext_dds_secure_um:`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] 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] 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 :link_connext_dds_secure_um:`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] 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] Fixes Related to Reliability Protocol and Wire Representation ------------------------------------------------------------- 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] Fixes Related to Entities ------------------------- 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] Fixes Related to Shipped Examples --------------------------------- 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] Fixes Related to Vulnerabilities -------------------------------- 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] 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] 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] Fixes Related to Security Plugins SDK ------------------------------------- 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] Fixes Related to Crashes ------------------------ 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]