EDIT: The latest patch (0.66) has fixed these issues. This post should now be used to learn how to better prevent these forms of exploits from appearing in your missions and mods.
Now that BI has fixed the issue in its latest Dev Patch I wanted to go over, in detail, how this method works, and how we all can work to prevent these types of flaws from happening again.
What is this bug?
This is a code execution exploit. What I mean by that is: It allows cheaters to execute SQF code from inside ArmA. This means they can run any scripts on your server without BattlEye interfering with them.
Why is this bad? It allows your server to be cheated on. Plain and simple. BattlEye can do nothing about this. You may wonder, why doesn’t BE just ban people for using this? The answer to that is quite simple as well. If BattlEye were to ban for this, they could subject any user to a false ban. You may have felt the effects of a Remote Execution or as it really should be dubbed Remote Code Execution on your server. If your server has ever been attacked where the hacker can: kill everyone, spawn a nuke, start a thunder dome, steal your server files or other extreme exploits of such nature, you have had a hacker with a Remote Execution on your server. If someone were to run the “Injection Code” on every player on your server, how could Battleye know who the actual cheater is and who the good guys are? It simply can’t. It can not determine who is abusing the injection and who happened to have it run on them via Remote Execution. This is why BattlEye can not ban for this.
What causes this bug?
There are actually two causes to this bug. Both stem from UI Code Execution. They both abuse BIS_fnc_parseNumber.
The problem in this regard is how parseNumber works. When it detects a string being passed into it, instead of using the parseNumber command, it uses call compile. Basically, instead of using a new feature in the game, BI never edited this file, leaving it open to code execution via the call compile commands. This fix is relatively simple for BI. The variables igui_bcg_rgb_a, igui_bcg_rgb_r, igui_bcg_rgb_g, and igui_bcg_rgb_b all use BIS_fnc_parseNumber if they contain a string value. This is how the cheater executes code. They simple set one of these values to their script and end it with a number.
For Example: profileNamespace setVariable [“igui_bcg_rgb_a”,”hint ‘run code’;0.4″];
Customizable UI layout
The script executed by the customizable layout UI is this:
The problem with this is that for each variable if it contains a string it will use BIS_fnc_parseNumber to get a number from it. This has the same effects as above, just in a different context.
With this, the _presetName must = “”. In order to do this, the cheater must also change the preset variable that is passed into the the UI function as shown below.
Here is how I went about doing that:
This will set the preset to an empty string (“”) and inject the code that is to be executed into IGUI_grid_mission_X. Essentially, bypassing any needed input from the person using it.
How to patch this on your server / mod
If you create a mod
You need to override parseNumber. As of now, I have not looked into the new patch BI released, however overriding parse number will be the fix for your mod on the current patch.
In your config file for functions, You need to add this.
Not word for word of course, but override ConfigFile >> “CfgFunctions” >> “A2” >> “Numbers” >> “parseNumber” with your own function.
Now your parseNumber.sqf should be changed. Here is the change.
This fix is only a “temporary” workaround, sure the code could be executed using a more complex method than what my example was, but this will patch the current execution exploits out there. This removes all the “code” leading up to the number, removing any malicious
If you run your own server
If you run your own server, this fix is “simpler” however less effective in a sense. You can still patch the bug. However, you can not “prevent” the bug (Ie. You can not stop the bug at its source).
As I showed in my previous post, You need to have the profileNamespace fix. This will need to be in your client code until the next BI patch comes along.
This profileNamespace fix WILL patch the bug. However, it does not prevent the bug. You will have to wait for BI to push their next patch to remove this code.