Here's what's up.
At the moment, the Arma series suffers from a flawed multiplayer architecture. Clients have unlimited power to modify game state, which means creating/deleting vehicles and weapons, modifying variables on clients and the server (the publicVariable family of commands), straight-up remotely executing SQF code, and other things.
As a long-time Arma 2 player (from way before DayZ) and server admin, I can say this has been a problem forever. The numbers of cheaters did increase after DayZ but the number was quite far from 0 before.
In Arma 2, after DayZ came out and brought these issues into the spotlight, BattlEye introduced
server-side event filters which allowed admins to log these events, as well as block and kick people for them. (That forum post hasn't been updated in awhile, and there have been several new filters added since. The best "documentation" for them is the
DayZ community ban list, which is updated by Dwarden and others.)
Unfortunately, that is a BattlEye feature so it is not currently available for Arma 3.
I haven't been playing Arma 3 much recently, so I haven't encountered this issue or had any chance to analyze it, but from reading
what was said by Tonic (which now appears to be removed from the BI forums), the problem would appear to be that BIS functions are being replaced. There are a few ways one could accomplish this - publicVariable would be the easiest, but since anyone can (at the moment, without BattlEye) execute **any** arbitrary SQF code on every machine, anything is possible.
BTW, this has been possible
forever and was known about (and an issue) since at least August 2012. And it's possible on all BIS_ functions, not just BIS_fnc_MP.
I should note that, while arbitrary code execution sounds bad (and it is), an attacker would be limited to the capabilities of the SQF VM. Not much is possible here - loadFile should only work within the Arma directory, callExtension (which would call a function in a DLL) should only load DLLs in mod folders, and AFAIK copying from clipboard was removed in one of the OA patches. That doesn't mean there isn't any exploit in the SQF VM that could allow for more dangerous stuff, but I'm not aware of one, AFAIK none have been found before and if there was, I would hope and assume BI would patch that quickly (it would be quite urgent for them, obviously).
Now, just imagine what will happen when they add a JVM...
So, what is the **real** solution to this?
Don't give the fucking client any power. Why the fuck are clients able to modify the variable space of other machines, execute arbitrary code anywhere, or otherwise modify game state?!?
All of this BattlEye stuff, while a remarkable effort on BattlEye's part, is a band-aid fix.
The DayZ standalone will fix this, but apparently Arma isn't important enough.
What they **should** have done is to provide two APIs - a legacy API, which maintains backwards compatibility and allows all this insecure bullshit, and a new API (hopefully not in SQF, as that's a POS) that doesn't. I agree that there's too much Arma content from the past decade to just say "fuck it," but that doesn't mean BI shouldn't start encouraging more secure practices going forward.
And quite frankly BI are retards for introducing
even more functionality for untrusted clients to execute arbitrary code on other machines. They should be trying to encourage mission makers to move away from this, not adding more functions to make this easier!
Anyways, on for some good news...
Assuming they keep this flawed architecture in Arma 3, the band-aid fix from BattlEye will be possible, hopefully as soon as BattlEye is added.
We have publicVariableServer and publicVariableClient now. That provides secure communication between the server and individual clients. With some cooperation from mission developers, future missions can hopefully be written in a manner that allows full utilization of the BattlEye filters to block **everything** and only allow a few publicVariable names.
Full utilization of BE filters = preventing remote execution of arbitrary code and game state changes from clients (vehicle creation and deletion, remote teleport, adding weapons to gear boxes, etc.) and only allowing certain variable names to be changed (no overwriting BIS_ functions) = none of this crap is possible. No more carpet-bombing the map, teleporting everyone into the sky, attaching rockets to everyone's vehicles, giving everyone a black screen, etc.
.
