Arma 3 “Old Man” SQF Execution Exploit

There is a nice old exploit that I never made a post about. This is the Layout exploit. When the player modifies their Layout through the game options, there is a nice little execution opportunity. The position of the HUD elements need to be saved into the profile, and are often parsed with parseNumber. I checked the script RscDisplayOptionsLayout.sqf found in the UI_F.pbo
Here is the code I found that was interesting:

If the variables for posX, Y, W, H are non-nil and the presetName is not an empty string, the values of posX, Y, W, H are all run through parseNumberSafe. This is good. If we can set the value of these in the UINamespace, we could use this section of code to trigger parseNumberSafe. Digging deeper, this code is executed when the layout is “applied” through the Okay button.

So easy enough, but what should the preset name be? To figure this out, I dug through CfgUIGrids. You can do so yourself, but I will tell you, the only preset name that is valid is “Arma3” for both categories “IGUI” and “GUI”. With this knowledge, we should set the variable for both of these categories to the value Arma3.
With that done, we can recreate the foreach loops above, and instead of reading from the uiNamespace variables, we can write to them. We write our exploitable config path, and the parseNumberSafe function should run our code.

To test this, we run this in the 3DEN editor and click “Options->Game->Layout->Okay->Okay” to trigger it. Tada! We have just created another SQF execution exploit in Arma 3!

Here is the complete exploit source:

On a more serious note, I have been finding exploits like this since Arma 3 Apex was released. Before then, I never really looked into them. The way BI handles UI positioning, requiring code execution to parse their position properly, is a very insecure way of handling it. The engine should have been provided native capabilities for these math calculations, and not some simple scripted system. It also seemed to be kind of arrogant of them to think that their new parseNumber function was so safe as to actually call the function parseNumberSafe. Honestly, I am willing to bet any SQF developer who is told “Hey there is an exploit in parseNumberSafe” would find this issue in under 10 minutes.

For server owners, I went ahead and created a patch. You should include this inside the client init of your server. As long as this code executes on the client before they can interact with the UI, you will catch anyone abusing the layout exploit. Here is the source code: Download:
For simplicity, banning could be a simple remoteExec call that you have filtered in remoteExec.txt

Note: this exploit has been patched as of SPOTREP #00094.

Pages: 1 2 3