Skip to content
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

Validate roll in unoccupied sync #624

Merged
merged 3 commits into from
Feb 7, 2023

Conversation

xunder-matth
Copy link
Contributor

No description provided.

@NexiusTailer
Copy link
Contributor

NexiusTailer commented Jan 30, 2023

direction also must be validated, see this.

There are two rules that the roll and direction vectors must comply with:

  1. Range of values. roll and direction can be valid if they > -1.0 and < 1.0 (NaN values must be also discarded)
  2. These vectors must be orthogonal to each other

So, the checks by the link above consider both things and cover all possible cases.

@xunder-matth
Copy link
Contributor Author

direction also must be validated, see this.

I validated roll because it can be abused to crash other players. I tried recreating crash with direction but I didn't get it to work. However looking at link you sent we should probably validate all data sent just to be sure it can't be exploited.

@NexiusTailer
Copy link
Contributor

NexiusTailer commented Jan 30, 2023

I validated roll because it can be abused to crash other players. I tried recreating crash with direction but I didn't get it to work.

Download any unoccupied ("quantum") crasher and check the basic ways of how they modified both direction and roll. Both of them can get any invalid values out of range (or even inside the range, but non-orthogonal) and they are all produce the same effects in the end for all streamed players (lite result is when the unoccupied vehicle just becomes invisible and more damage will occur if player are in spectating on this vehicle or surfing on it).

However looking at link you sent we should probably validate all data sent just to be sure it can't be exploited.

I'm pretty sure that at least NaN/infinity cases cannot be achieved in omp server even now because iirc some filter for all float data was built-in somewhere while processing the sync. The checks that really needs to be added are actual ranges (-1.0 < roll/dir < 1.0) and orthogonal check for two arrays (vectors) to each other.

Copy link
Collaborator

@AGraber AGraber left a comment

Choose a reason for hiding this comment

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

Any reason for it to be std::fabs(1.0 - glm::length(unoccupiedSync.Roll)) >= 0.000001 instead of std::fabs(glm::length(unoccupiedSync.Roll)) > 1.0? I'm rusty on all this stuff, but I just wanna know what's the deal behind that

@AmyrAhmady AmyrAhmady merged commit b1ff20d into openmultiplayer:master Feb 7, 2023
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.

5 participants