Jump to content
Sign in to follow this  
killzone_kid

compileFinal is nice but lets improve security even more!

Recommended Posts

Just thought:

If I use compileFinal command, will that script still take input values from the execVM command?

Share this post


Link to post
Share on other sites
Dan;2386080']Just thought:

If I use compileFinal command' date=' will that script still take input values from the execVM command?[/quote']

It turns into a function like.

head_fnc_spawn = compileFinal "'mi-8' createVehicle (getpos _this);"

then you use either spawn or call

player call head_fnc_spawn;
player spawn head_fnc_spawn;

Share this post


Link to post
Share on other sites
there are many commands like this, and majority of them were and are used actively by community content makers ...

so it's either remove / fix / secure all of them or none ...

but such step would result into removal of any backward compatibility to most of A1,A2,OA scripted content ...

Break eeeeeeeeeeeeeeeet!

TBH it's ArmA 3 not 2 not 1. Porting content already requires some adjustments so it is not backward compatible without fiddling with it first.

Share this post


Link to post
Share on other sites
there are many commands like this, and majority of them were and are used actively by community content makers ...

so it's either remove / fix / secure all of them or none ...

but such step would result into removal of any backward compatibility to most of A1,A2,OA scripted content ...

I don't know a lot about security fom a coding pov, but as a player I would welcome it. Reading through this thread, it seems there are 101 ways to transmit code over the network. Would be nice to boil it all down to using PV's or some other protected/monitorable process. Might actually make it easier for mission makers in the long run.

Share this post


Link to post
Share on other sites
Dan;2386080']Just thought:

If I use compileFinal command' date=' will that script still take input values from the execVM command?[/quote']

Yes, the code gets locked from overwriting thats all.

Share this post


Link to post
Share on other sites
Yes, the code gets locked from overwriting thats all.

awesome, thank you for answering

Share this post


Link to post
Share on other sites

Add a compatibility switch (setting) for servers - disabled by default, make it active for SP, and close down all the remote code execution (and remote effect) loopholes finally.

Otherwise the A3 release will be just the disaster we are all too used too since OFP..

BI and public play MP content makers just have to update their scripts to proper secure standards.

Share this post


Link to post
Share on other sites

This ^^^ Oh and before "we have to wait for Battleye" we know what disaster it turned out to be when dayz got popular. A good hack and everyone is doing it BE or no BE.

Share this post


Link to post
Share on other sites
This ^^^ Oh and before "we have to wait for Battleye" we know what disaster it turned out to be when dayz got popular. A good hack and everyone is doing it BE or no BE.
please, do not spread FUD, BE was and is quite effective in OA

---------- Post added at 13:42 ---------- Previous post was at 13:42 ----------

;2386145']Add a compatibility switch (setting) for servers - disabled by default' date=' make it active for SP, and close down all the remote code execution (and remote effect) loopholes finally.

Otherwise the A3 release will be just the disaster we are all too used too since OFP..

BI and public play MP content makers just have to update their scripts to proper secure standards.[/quote']

that's one of internally discussed solutions, to reach A3 default MP w/o deprecated / obsolete commands

Share this post


Link to post
Share on other sites

BE is essentially too and the best solution available.

Share this post


Link to post
Share on other sites
please, do not spread FUD, BE was and is quite effective in OA

I'm not denying this, it is effective yes, to ban and keep banned from servers. But at some point a new hack appeared undetectable by BE and there was no fix for about a month and that is when it went rampant. That happened soon after BE got decompiled. I remember what happened pretty vividly as we were running pretty popular server at the time. There was one weekend we were on constant watch and banned maybe a dozen script kiddies. So I am not spreading any FUD I'm just saying how it is. You cannot rely on BE to solve all your problems.

Share this post


Link to post
Share on other sites
To be honest, I like the idea of breaking pre-A3 content, due to the fact that I, and many others, are fed up with the typical copy-paste content that has been floating about for years and run like turd....
Break eeeeeeeeeeeeeeeet!

TBH it's ArmA 3 not 2 not 1. Porting content already requires some adjustments so it is not backward compatible without fiddling with it first.

What's the say, "if s/he doesn't tap, you gotta break that shit"?

But yeah, I'm looking forward to hearing more about what the security strategy is going to be moving forward after the stable build gets "the fix".

Share this post


Link to post
Share on other sites
there are many commands like this, and majority of them were and are used actively by community content makers ...

so it's either remove / fix / secure all of them or none ...

but such step would result into removal of any backward compatibility to most of A1,A2,OA scripted content ...

Yes, there is no other way. Leaving just 1 remote execution command will be just as bad as leaving all of them in, so it really is "all or nothing".

If there's a time to do this sort of thing, it is now, with everyone being understanding due to the massive hacking and the game still being in alpha state so everyone who made something are well-aware that they might need to update it.

Of course, having proper mod synchronization (BIS-style Play withSIX, even if it only comes with minimal functionality needed to get the correct mods) will basically remove all situations that require using those commands.

Oh, and createUnit is just EVIL! Luckily we can still get the unit by getting the array of units in the group, as at least the group is something we already have...

Share this post


Link to post
Share on other sites

Well, someone mentioned BIS function BIS_fnc_codePerformance in another thread

/*
Author: Karel Moricky

Description:
Measures how much time it takes to execute given expression

Parameter(s):
_this select 0: STRING - tested expression
_this select 1 (Optional): ANY - Param(s) passed into code (default: [])
_this select 2 (Optional): NUMBER -  Number of cycles (default: 10000)

Returns:
NUMBER - avarage time spend in code execution [ms]
*/
private ["_code","_params","_cycles","_codeText","_timeResult"];

_code = [_this,0,"",[""]] call bis_fnc_param;
_params = [_this,1,[]] call bis_fnc_param;
_cycles = [_this,2,10000,[0]] call bis_fnc_param;

//--- Compile code (calling the code would increase the time)
_timeResult = 0;
_codeText = compile format [
"
	_time = diag_ticktime;
	for '_i' from 1 to %2 do {
		%1
	};
	_timeResult = ((diag_ticktime- _time) / _cycles) * 1000;
",
_code,
_cycles
];

//--- Execute testing
"----------------------------------" call bis_fnc_logFormat;
["Test Start. Code: %1",_code] call bis_fnc_logFormat;
["Test Cycles: %1",_cycles] call bis_fnc_logFormat;
_params call _codeText;
["Test End. Result: %1 ms",_timeResult] call bis_fnc_logFormat;
"----------------------------------" call bis_fnc_logFormat;

_timeResult

This function will not only execute your code on remote machine if you call it with BIS_fnc_MP, it will also execute your code as many times as you want.

:j:

You see this is my problem with this approach. You don't need this function, you can write your own performance test bit of script as fast as if not faster than having to learn about this function and remember its params. A massive security hole trying to make coder life easier. In fact this is a headache function leaving it like that in ArmA 3 package.

Edited by Killzone_Kid

Share this post


Link to post
Share on other sites
Well, someone mentioned BIS function BIS_fnc_codePerformance in another thread

/*
Author: Karel Moricky

Description:
Measures how much time it takes to execute given expression

Parameter(s):
_this select 0: STRING - tested expression
_this select 1 (Optional): ANY - Param(s) passed into code (default: [])
_this select 2 (Optional): NUMBER -  Number of cycles (default: 10000)

Returns:
NUMBER - avarage time spend in code execution [ms]
*/
private ["_code","_params","_cycles","_codeText","_timeResult"];

_code = [_this,0,"",[""]] call bis_fnc_param;
_params = [_this,1,[]] call bis_fnc_param;
_cycles = [_this,2,10000,[0]] call bis_fnc_param;

//--- Compile code (calling the code would increase the time)
_timeResult = 0;
_codeText = compile format [
"
	_time = diag_ticktime;
	for '_i' from 1 to %2 do {
		%1
	};
	_timeResult = ((diag_ticktime- _time) / _cycles) * 1000;
",
_code,
_cycles
];

//--- Execute testing
"----------------------------------" call bis_fnc_logFormat;
["Test Start. Code: %1",_code] call bis_fnc_logFormat;
["Test Cycles: %1",_cycles] call bis_fnc_logFormat;
_params call _codeText;
["Test End. Result: %1 ms",_timeResult] call bis_fnc_logFormat;
"----------------------------------" call bis_fnc_logFormat;

_timeResult

This function will not only execute your code on remote machine if you call it with BIS_fnc_MP, it will also execute your code as many times as you want.

:j:

You see this is my problem with this approach. You don't need this function, you can write your own performance test bit of script as fast as if not faster than having to learn about this function and remember its params. A massive security hole trying to make coder life easier. In fact this is a headache function leaving it like that in ArmA 3 package.

It could stay in, if BIS perhaps implemented some kind of blacklist for BIS_fnc_MP, and also enable a field in server.cfg, or description.ext, to add specific blacklisted functions for BIS_fnc_MP. Have it IN ENGINE, and not just a BE tack-on. People can waffle on as much as they like about how 'good' BE is, but it's got a marred history of being just plain bad... Not FUD... Fact....

Share this post


Link to post
Share on other sites

Why is remote code execution via BIS_fnc_MP needed at all? (or via other BIS_fnc)

IMO it is not - its just a convenience feature and should go.

Share this post


Link to post
Share on other sites
;2386813']Why is remote code execution via BIS_fnc_MP needed at all? (or via other BIS_fnc)

IMO it is not - its just a convenience feature and should go.

To make life easier, same principle I think.

Share this post


Link to post
Share on other sites

Problem is Kju, is that BIS uses this function to all high-hell, all through their library.... and, as it stands, it's the only way for an addon to do stuff over the network, to not-addon using clients. Though, mind you, I'm not a big supporter for this whole non-consensual add-on message code slinging.

Share this post


Link to post
Share on other sites

What many still seem to miss is that the main problem wasn't the remote execution, but rather the fact you could execute code that was saved earlier by a script that was run during a mission. That could be done without finding a way around the signature check system (not to mention the upcoming battleye). In the end, no matter how much you limit scripting, as long as the engine is designed to work in the ArmA world (and there's really no other way to do it in a simulation, as fully authoritative servers simply don't work in the simulation/ArmA world), someone who finds a way to run his own scripts is going to ruin everyone's day - No matter what commands are removed/improved.

The only reason I'm not really complaining about the removal of said commands is because I think broadcasting code over the network is simply a bad idea - It's ugly design-wise and quite silly performance-wise. Making people run code they do not have is the only real need, but I think letting them have that code (either via proper mod synchronization or via including the code in the mission file) is the right way to go at it, and not broadcasting the code over the network with a public variable. In any case, I think we're about to see just as many trouble in terms of MP hacking regardless of whether those commands survive or not.

Back to the topic of security, a question: As I have no idea how uiNameSpace actually works, will it be possible for someone who knows a name of a function I define in my mission to pre-compile his own using the same function name, using compileFinal, and save it in uiNameSpace and thus break my mission as it tries to save my own function into the variable?

Share this post


Link to post
Share on other sites

Just thought of another possible exploit because of the code transfer over network. This time it actually involves the new compileFinal.

So lets say you have your public variable MY_PV that you use to broadcast an array of values over to other machines. Now if I do this on my machine

MY_PV = compileFinal ""; publicVariable "MY_PV";

I am effectively destroying the public variable MY_PV as it is now cannot be overwritten.

Share this post


Link to post
Share on other sites

nothing new, that's why you don't use publicVariable that way and learn to use publicVariableClient and send to each client unique variable

sure problem with abuse of overwriting public variables can be lowered (aka we on it)

Share this post


Link to post
Share on other sites

Radioman the RE part of BIS_fnc_mp is hopefully just a forgotten feature. If it is actually used in BI scripts, those instance have to be changed to a proper design.

Overall there should be a SQF command to remote execute code to allow it to be filtered by BE and deactivated by default.

uiNamespace and probably also profileNamespace have potential for abuse. Depends if the BI library also has weak design there.

To make the problematic commands unavailable by default, and usable in SP and via a server.cfg switch seems like a good approach to me.

A lot of these security aspects have been discussed with Ondra in private CIT tickets already.

Yet it seems aside from Dwarden noone of the A3 team took notice or cared so far..

The client-server design of DZ SA won't become available to A3 any time soon.

Hence BI needs to work on improving the current design. BE alone is no perfect solution for the general public either.

There are lot of areas to work on and BI just has to make it a priority and assign resources to it.

Otherwise we are to see the same drama and huge negative impact we had in OFP, A1, A2, OA, DZ, and A3 alpha..

Share this post


Link to post
Share on other sites
;2388548']A lot of these security aspects have been discussed with Ondra in private CIT tickets already.

Yet it seems aside from Dwarden noone of the A3 team took notice or cared so far..

Do we even know if Suma is still working on Arma 3?

Share this post


Link to post
Share on other sites
nothing new, that's why you don't use publicVariable that way and learn to use publicVariableClient and send to each client unique variable

sure problem with abuse of overwriting public variables can be lowered (aka we on it)

I've been considering this PVC approach, but need to know some facts, mainly..will for example

{

_myPV = "MY_PV" + getPlayerUID _x;

missionNamespace setVariable [_myPV, _myValue];

(owner _x) privateVariableClient _myPV;

} forEach all60Clients;

take 60 times longer than

MY_PV = _myValue;

privateVariable "MY_PV";

Not a problem for occasional use but what if you need server to update clients quite often?

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×