Closed mirusu400 closed 7 months ago
Hi @mirusu400, thanks for using Fast DDS.
As you have described in the expected behavior, setting the HistoryQoS kind as KEEP_LAST
and the depth = 0 is inconsistent and Fast DDS should address it by handling the error.
The PRs including that error handling plus improving the documentation are attached to this issue, and once they are merged, this issue will be closed automatically. Please feel free to re-open it if necessary.
Thanks for your report!
Is there an already existing issue for this?
Vulnerability Type
DoS
Expected behavior
When setting depth = 0 and kind = KEEP_LAST_HISTORY_QOS for DataReader’s HistoryQosPolicy, handle errors or receive DataWriter’s data properly.
Current behavior
When setting depth = 0 and kind = KEEP_LAST_HISTORY_QOS for DataReader’s HistoryQosPolicy, the program aborts upon receiving DataWriter’s data.
Attack Vectors
To exploit vulnerability, victim must receive data with setting depth = 0 and kind = KEEP_LAST_HISTORY_QOS for DataReader's HistoryQosPolicy.
Steps to reproduce
A quick simple:
Detailed Example: Fastdds-poc_src.zip
Test:
Cause error like:
GDB backtrace result:
Fast DDS version/commit
v2.11.2
v1.1.1
Platform/Architecture
Ubuntu Focal 20.04 amd64
Transport layer
Default configuration, UDPv4 & SHM
Additional context
No response
XML configuration file
No response
Relevant log output
No response
Network traffic capture
No response