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

Fix: [Script] Ensure the saved script strings are properly validated and terminated when being read from the save game #9336

Merged
merged 1 commit into from Jun 10, 2021

Conversation

rubidium42
Copy link
Contributor

Motivation / Problem

Just set the string data length to 255 and fill it will all non-zeros. When buf[255] is also non-zeros, this will read beyond the bounds when making the string. Similarly the maximum value of _script_sl_byte can only be 255 though 256 bytes are allocated for the buffer.

Description

Allocate just enough memory for a buffer of _script_sl_byte long.
Perform a string validation on the string coming from the save game ensuring termination and valid Utf8 characters

Limitations

Potentially a game script that put some non-Utf8 characters in their strings would get different information when loading compared to what they saved. However, a string should be a valid string. If you want something else stored, use an array of integers.

Checklist for review

Some things are not automated, and forgotten often. This list is a reminder for the reviewers.

  • The bug fix is important enough to be backported? (label: 'backport requested')
  • This PR affects the save game format? (label 'savegame upgrade')
  • This PR affects the GS/AI API? (label 'needs review: Script API')
    • ai_changelog.hpp, gs_changelog.hpp need updating.
    • The compatibility wrappers (compat_*.nut) need updating.
  • This PR affects the NewGRF API? (label 'needs review: NewGRF')

…and terminated when being read from the savegame
@@ -569,8 +569,9 @@ bool ScriptInstance::IsPaused()

case SQSL_STRING: {
SlObject(nullptr, _script_byte);
static char buf[256];
static char buf[std::numeric_limits<decltype(_script_sl_byte)>::max()];
Copy link
Member

Choose a reason for hiding this comment

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

This feels real dirty. Is lengthof not good enough?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, lengthof is giving you the numer of elements that are in an array. Here I am not looking for the number of elements in the array, but I am rather looking for the maximum value of _script_sl_byte as that's the maximum number of bytes that will be used of the buffer.

Practically 255 or UINT8_MAX would suffice, but those will break as soon as someone decides _script_sl_byte is to be a UINT16. Ofcourse it could just test whether _script_sl_byte is less or equal to lengthof(buf), but that will in its turn cause complaints about dead code since currently there is no way for _script_sl_byte to be larger than 255. Only once the type is made larger that becomes a possibility, and only then that code makes any sense.
This way the allocated buffer will always be large enough. Well, for uint16. For uint32 it will probably crash quickly due to allocating too much on the stack. The alternative would be to use 255 or UINT8_MAX and then some static_assert to ensure the value for _script_sl_byte is always within bounds, but that would likely include something similar to what I have written here.

@rubidium42 rubidium42 merged commit 2924ac4 into OpenTTD:master Jun 10, 2021
@rubidium42 rubidium42 deleted the script_unsafe_string_load branch June 10, 2021 20:03
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.

None yet

3 participants