aiortc
[SECURITY] aioquic may store an unlimited number of remote path challenges
Summary
aioquic may infinitely receive PATH_CHALLENGE frames and store challenge data in remote_challenges, resulting in unbounded memory usage. It may lead to a denial-of-service attack.
Tested Version
Latest git commit (9bc1e43)
Details
#483 appears to be the cause of this vulnerability. Although MAX_REMOTE_CHALLENGES is defined, the constant is not used. As a result, the remote_challenges queue can grow infinitely.
Suggestion
https://github.com/aiortc/aioquic/blob/9bc1e43d13be3f06339841aca7c8560825053371/src/aioquic/quic/connection.py#L2045
Check the length of remote_challenges before appending challenge data.
This issue is verified to be reproducible, by constantly writing path challenge frames, aioquic has consumed almost 10GB of memory and will eventually be killed by the OS.
https://github.com/aiortc/aioquic/blob/9bc1e43d13be3f06339841aca7c8560825053371/src/aioquic/quic/connection.py#L3040-L3041
Although connection.py's line 3041 empties network_path.remote_challenges, however, if the client chooses not to send an ACK message in response to the path response, aioquic does not go as far as this statement, causing the network_path.remote_challengesqueue to continue to accumulate.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
OK indeed if there is no ACK we won't flush this list of path challenges. I'd appreciate pointers to the RFC as to whether it even makes sense to accumulate path challenge, or just store the latest received challenge?
RFC 9000 states:
On receiving a PATH_CHALLENGE frame, an endpoint MUST respond by echoing
the data contained in the PATH_CHALLENGE frame in a PATH_RESPONSE frame.
@rthalley ?