Skip to content

fix: Detection and graceful handling of corrupt packets #2419

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Feb 23, 2023

Conversation

ShadauxCat
Copy link
Collaborator

Adds multiple ways to detect and handle corrupt packets that could otherwise cause issues and put the game into a bad state, or potentially cause crashes:

  • A "magic" value at the start of each packet helps when looking at packet dumps to see where potential start-of-packet is if the data gets offset (as was seen in the recent BatchSendQueue corruption bug)
  • A "size in bytes" value helps us detect if the packet has been truncated or if garbage has been added to the end
  • A "hash" value helps to detect when the other values are correct but one or more bytes within the packet have been corrupted

Additionally, code has been added to refuse to process ConnectionRequestMessage or ConnectionAcceptedMessage on an alredy-established connection, or either of those being received by the wrong side, as those could otherwise be used as a vector for attack by a malicious actor and render the framework completely broken.

In all cases, if these issues occur, the log requests the user to file an issue with us with the full hex dump of the packet that was received.

Changelog

  • Added: Added detection and graceful handling of corrupt packets for additional safety.

Testing and Documentation

  • Includes unit tests.
  • Includes integration tests.
  • No documentation changes or additions were necessary.

Adds multiple ways to detect and handle corrupt packets that could otherwise cause issues and put the game into a bad state, or potentially cause crashes:

- A "magic" value at the start of each packet helps when looking at packet dumps to see where potential start-of-packet is if the data gets offset (as was seen in the recent BatchSendQueue corruption bug)
- A "size in bytes" value helps us detect if the packet has been truncated or if garbage has been added to the end
- A "hash" value helps to detect when the other values are correct but one or more bytes within the packet have been corrupted

Additionally, code has been added to refuse to process ConnectionRequestMessage or ConnectionAcceptedMessage on an alredy-established connection, or either of those being received by the wrong side, as those could otherwise be used as a vector for attack by a malicious actor and render the framework completely broken.

In all cases, if these issues occur, the log requests the user to file an issue with us with the full hex dump of the packet that was received.
@ShadauxCat ShadauxCat requested a review from a team as a code owner February 21, 2023 18:47
Copy link
Collaborator

@NoelStephensUnity NoelStephensUnity left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@ShadauxCat ShadauxCat merged commit 03c20ac into release/1.3.0 Feb 23, 2023
@ShadauxCat ShadauxCat deleted the fix/messaging_pants_and_suspenders branch February 23, 2023 18:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants