With the “Old Man” update out now, I decided to take another look at the Functions and UI scripts to see what fixes they implemented, and to look for a new exploit for SQF execution.
To my surprise, I was greeted with BIS_fnc_parseNumberSafe. This neat little function is a “fix” for their previously broken BIS_fnc_parseNumber. They implemented a smart little trick to prevent unwanted code execution while parsing string types.
Just to refresh you on BIS_fnc_parseNumber & why it was truly awful. Here is a small snippet from it:
_number is just executed with no checks!
Here is the same snippet from the new BIS_fnc_parseNumberSafe:
This is a bit more complex. It is using some SQF functionality that I rarely use. Breaking it down, the string stored in _this is first checked if it contains any contents not allowed. If any content is found that is not allowed, _res gets the value of 0. If _res has a value, it will not execute the text. First, let’s figure out what is and is not allowed:
So, in theory, if the text contains any code not defined in this list, it will not execute. Testing that out with [“hint ‘test’;0”] call BIS_fnc_parseNumberSafe; we can see that it does do it’s job. It does that job well.
Continuing with our analysis, we can find other locations in BIS_fnc_parseNumberSafe that also executes call compile:
Looking at these, if the text value comes from a config entry, it will execute it without question.