compileFinal is nice but lets improve security even more!

[eddieck 10]

;2384878']remote execution has to go no matter what - in all forms

+1000

There is nothing that can be done with it, that can't be done with PVEHs.

And if a mission developer decides to (ab)use PV for it, that's their own (dumb) choice.

[Twix 1]

i parser for that and use it quite often, so this note is irrelevant, for me it has reason to got the mission file as smaller as possible, same goes for the dynamic data flying over network or else ...

It's true of course, but....in this day and age who cares about 90kb on a mission file? It's good practice but nothing to drive yourself nuts over. Clean and commented code is WAY more important than the mission size to me.

Any code that a regular coder can't just open and immediately understand is done wrong in my book, even if it works flawlessly.

A 4Mb instead of 5Mb MBmission on the other hand, who cares...

I agree 200% for dynamic data though, especially what you push out and when (and if you really need to).

[eddieck 10]

It's true of course, but....in this day and age who cares about 90kb on a mission file? It's good practice but nothing to drive yourself nuts over. Clean and commented code is WAY more important than the mission size to me.

Any code that a regular coder can't just open and immediately understand is done wrong in my book, even if it works flawlessly.

A 4Mb instead of 5Mb MBmission on the other hand, who cares...

I agree 200% for dynamic data though, especially what you push out and when (and if you really need to).

In my experience JIP causes desync for all clients, so any reduction in the amount of data to be sent to a JIP client is a good thing. Just hopefully people will provide the unminified version upon request (i.e. include a README in the PBO with details on obtaining it, preferably a DH, GitHub, Bitbucket, etc.).

It would be nice if we'd finally get HTTP mission downloads though - then file sizes wouldn't be a concern, there would be less JIP desync, and we could use CDNs for even faster distribution to players.

[Radioman 6]

I vote that all 'global effect' functions become local effect, with the exception of perhaps 'passive' methods, like createmarker etc.

Good mission coding practice would be to make the server handle if/how/when an event should cause global effect, via PVEH, and NOT have any call compile _pvVar anywhere, as that's simply stupid. Use a flag based PV, as you'd only need the passed variable content be a few characters long.

Edit:

I also vote that missions that have 'disableGlobalEffect = true;" set in their .ext, override a server's disableGlobalEffect, if it is not explicitly set. (ie, not in the config)

That way, admins can choose whether or not to allow global effect or not. I believe, however, that BIS would need to implement an execution wrapper for addons etc, so that addons can have, in their config.cpp, a flag that allows global exec of calls it does, vs having them universally blocked

You may say "BE Filters do this!", but, you can't cover all eventualities without breaking missions, if you have a cycle. You cannot expect server admins to de-pbo all missions, check through them, make sure the BE filters don't clash, and make adjustments.... Most server admins cannot even tie their shoe laces.... BE filters were only marginally effective on Arma 2, and they were set up on static missions (DayZ) where the code rarely changes, and yet still hackers ran rampant....

So.... BIS needs to publish a plan for all this, for all of us to critique, and white-hat the crap out of, until it's covered all bases of security, and functionality.

I don't give a wooden nickle about breaking people's code. We don't want the same old crap ported up from A2, which was ported up from A1.... It's all really REALLY bad code, full of holes, from a long passed era of 'Pre-mainstream Arma'. Batten down the hatches, and make it so only SMART people can only do the RIGHT thing.... Your audience has changed, and so must your outlook on security, BIS.

Edited April 29, 2013 by Radioman

[killzone_kid 1332]

_code={player setdamage 1;};

_string ="{player setdamage 1;};";

call _code;

call compile _string;

Both have the same result.

That's why removing code transfert doesn't change much. The only thing BIS can do if they don't want to change Arma 3 architecture (I'm my opinion, they should change it, Alpha is still the time to do) is to remove the integrated local client code receive & execution functions. Which is what they are doing with the remove of the SVI PCI commands. Then people have to make their own for they addons / missions if they need to execute code on remote machine (with all the safety issue it can be). But It will not be inside as basis.

Firstly your compiled code wont work and throw an error. Secondly there is no harm in transferring strings. The reason why code is harmful is because hackerfunction = {}; publicVariable "hackerfunction" now every client has the function on their machine. all you need now is to use BIS_fnc_MP to pass the name of the function and parameter. Now please enlighten me with the similar procedure for the string exploit.

[Radioman 6]

Firstly your compiled code wont work and throw an error. Secondly there is no harm in transferring strings. The reason why code is harmful is because hackerfunction = {}; publicVariable "hackerfunction" now every client has the function on their machine. all you need now is to use BIS_fnc_MP to pass the name of the function and parameter. Now please enlighten me with the similar procedure for the string exploit.

He's going on about how people are daft and put 'call compile _pvVar' in their PVEHs.... So, his argument is a tad invalid, as a workaround already exists to fix that issue.... Simply, don't trust stupid people to program missions. call compile public variables.

Edited April 29, 2013 by Radioman

[jacmac 2]

;2384878']remote execution has to go no matter what - in all forms

I don't really agree with this. Remote execution is not necessarily bad, but it has to have some kind of check process. A piece of code created and issued to clients by the server is not a bad thing. It is bad if clients can cause the server to issue bad code. It is also bad if clients can issue bad code to other clients. It seems like there is little distinction between a client and a server in Arma, this is where the change needs to take place. There should be a huge difference.

[.kju 3245]

Checking/validating the code is probably (practically) impossible. And why do you need RE at all?

The only things I can think of is an admin console, server side addons and optional (client) addons.

Normally none of these are necessary. Those cases should be made possible by other means (allowConsole = true/false; allowServerSideRemoteExecution = true/false; etc in the server.cfg).

[xeno 234]

The reason why code is harmful is because hackerfunction = {}; publicVariable "hackerfunction" now every client has the function on their machine. all you need now is to use BIS_fnc_MP to pass the name of the function and parameter.

You don't even need BIS_fnc_MP to execute any code you want remotely.

Add for example a MP killed EH to the player object on a client and press ESC->Respawn, the MPKilled code gets now executed on all connected instances, means all clients and the server.

As long as BIS_fnc_MP isn't changed (clients should never be able to execute any available function/script file or code remotely) and as long as the MP eventhandlers transfer code over the net instead of using preregistered code nothing will really change.

I also wonder why clients can use any setPos command or setDamage on other clients player objects. Scripting commands like these should be limited to the local player object.

Xeno

[killzone_kid 1332]

;2385204']Checking/validating the code is probably (practically) impossible.

dont need to check it or validate' date=' just to detect, you can already do this typeName == "CODE" in scripts why not perform this check by deafult before sending data over to other clients (I mean on engine level)?

You don't even need BIS_fnc_MP to execute any code you want remotely.

Add for example a MP killed EH to the player object on a client and press ESC->Respawn, the MPKilled code gets now executed on all connected instances, means all clients and the server.

As long as BIS_fnc_MP isn't changed (clients should never be able to execute any available function/script file or code remotely) and as long as the MP eventhandlers transfer code over the net instead of using preregistered code nothing will really change.

I also wonder why clients can use any setPos command or setDamage on other clients player objects. Scripting commands like these should be limited to the local player object.

Xeno

Good point. This is why code in global EH should be changed to function name since we now have compileFinal. I suppose it will be easier for BIS to make a couple of new event handler commands instead of messing with the old ones, something like

addMPEventHandler2 [eventname, function name];

Edited April 30, 2013 by Killzone_Kid

[headswe 17]

Good point. This is why code in global EH should be changed to function name since we now have compileFinal. I suppose it will be easier for BIS to make a couple of new event handler commands instead of messing with the old ones, something like

addMPEventHandler [eventname, function name];

This is a good idea. make it work like bis_fnc_mp in regards to that too. allow us to choose target.

[b]player addMPEventHandler [eventname,function,target,isPersistent][/b]

bis_fnc_spawn and bis_fnc_execVM should also be removed.

[killzone_kid 1332]

This is a good idea. make it work like bis_fnc_mp in regards to that too. allow us to choose target.

[b]player addMPEventHandler [eventname,function,target,isPersistent][/b]

bis_fnc_spawn and bis_fnc_execVM should also be removed.

Agree, target yes, should be pretty handy, but persistent? It is an event handler you want it to fire when the event occurred, not sometime after when someone else is connecting, you can always use BIS_fnc_MP for it.

[headswe 17]

Agree, target yes, should be pretty handy, but persistent? It is an event handler you want it to fire when the event occurred, not sometime after when someone else is connecting, you can always use BIS_fnc_MP for it.

True, i was more thinking about non MP eventhandlers really.

player addMPEventHandler [eventname,function,target]

[font=sans-serif]object [/font][b]addEventHandler [type, function,target,[/b][b]isPersistent[/b][b]][/b]

[Radioman 6]

You don't even need BIS_fnc_MP to execute any code you want remotely.

Add for example a MP killed EH to the player object on a client and press ESC->Respawn, the MPKilled code gets now executed on all connected instances, means all clients and the server.

As long as BIS_fnc_MP isn't changed (clients should never be able to execute any available function/script file or code remotely) and as long as the MP eventhandlers transfer code over the net instead of using preregistered code nothing will really change.

I also wonder why clients can use any setPos command or setDamage on other clients player objects. Scripting commands like these should be limited to the local player object.

Xeno

+1. All global effect functions should at LEAST require locality of the arguments/affected object, in order to execute. and BIS should burn MP event handlers at the stake, like they did with setvehicleInit. It's exactly the same in regards to vulnerability, and doesn't really bring any functionality that cannot be done otherwise with a simple PVEH....

[columdrum 11]

You don't even need BIS_fnc_MP to execute any code you want remotely.

I also wonder why clients can use any setPos command or setDamage on other clients player objects. Scripting commands like these should be limited to the local player object.

Xeno

Yep and only the server should be able to execute them on non local objects, and for example createvehicle should be only be able to be executed on the server( maybe we should have a way to also make an execption with HC, but with the current implementation may be difficult), that would be a real security improvement, but also a great retro-compatibility impact, so any change like those should be always optional, since a lot of closed comunity servers doesn't need those new security features for anything.

[l etranger 5]

Firstly your compiled code wont work and throw an error. Secondly there is no harm in transferring strings. The reason why code is harmful is because hackerfunction = {}; publicVariable "hackerfunction" now every client has the function on their machine. all you need now is to use BIS_fnc_MP to pass the name of the function and parameter. Now please enlighten me with the similar procedure for the string exploit.

Yeah the brackets should be left out of the string. I didn't though about _code = function when i written that. will code transfert still be a problem with compilefinal ?. My point was more forward securing the root first before securing the branch of the tree.

[killzone_kid 1332]

Good read http://alpha.arma3.com/sitrep-00009 though I don't believe that proposed here solutions will lead to restriction of freedom. Commands that have been removed do not restrict freedom in any way because you can substitute them with more secure alternatives, same goes for compileFinal. You are mission creator you should be in control. I don't think someone will compileFinal own code then go complaining he cannot modify it. Don't compileFinal, just compile. Options have never restricted freedom, options only enhance freedom.

[jacmac 2]

Yep and only the server should be able to execute them on non local objects, and for example createvehicle should be only be able to be executed on the server( maybe we should have a way to also make an execption with HC, but with the current implementation may be difficult), that would be a real security improvement, but also a great retro-compatibility impact, so any change like those should be always optional, since a lot of closed comunity servers doesn't need those new security features for anything.

I agree, although I'm hardly worried about retro-compatibility. It might be a pain to port over older Arma mods if the devs really shake things up in the name of security, but it's worth it in the long run.

[chortles 263]

To be honest the dev position laid out in the SITREP seems clearly to be that they're going to shake up things in the name of security, closed community-not-needing-security-features be damned, since the prior exploit was able to spread, and acknowledging "the response to deliberately removing three scripting commands: improved security, but broken community content" suggests that they're taking an "it's worth it in the long run" attitude as well. Heck, have the SITREP's comparing of things to DayZ as being even more secure:

I do not believe for a moment we can have both freedom and fully secure MP without serious restrictions. The only seemingly valid method would be an approach taken by the DayZ project via its MMO architecture. Keep in mind this concept does not gel with Arma 3 as it was designed - it means all client actions are validated on a server, and this makes client-side modding and scripting much more difficult. Acceptable for DayZ, not for Arma 3. We will however do our best to improve security, reduce vulnerabilities and walk the fine line between freedom and security based on your feedback.

[galzohar 31]

MPKilled (and whatever other EHs might be doing the same thing) is obviously just as vulnerable. Heck, I avoided using it just because I was like "eh, this thing sends code across the network (every time someone dies)?! I guess I'll go an extra mile and write a PVEH and use a normal killed EH"...

So yes, maybe I'm biased because I've always worked around needing those commands anyway, but in the end it makes little sense to have them, even if just from a network traffic perspective.

The problem of not being able to broadcast mod-based code to clients who don't have the mod should be solved by proper mod synchronization (style Play withSIX) and/or the already existing automatic mission downloading system. Definitely not by broadcasting code over the network through the scripting engine. You should really be complaining about needing to use such ugly workarounds in the first place rather than complaining about the removal of the workarounds.

[xeno 234]

To be honest the dev position laid out in the SITREP seems clearly to be that they're going to shake up things in the name of security, closed community-not-needing-security-features be damned, since the prior exploit was able to spread, and acknowledging "the response to deliberately removing three scripting commands: improved security, but broken community content" suggests that they're taking an "it's worth it in the long run" attitude as well. Heck, have the SITREP's comparing of things to DayZ as being even more secure:

Please do all the people here in that forum a favour and keep yourself out of threads when you have no idea what you are talking about, Thank you.

Xeno

[killzone_kid 1332]

One other thing that makes no sense and needs to be addressed is createUnit command

As you all know createUnit does not return object of a unit you created, like createVehicle or createAgent, in fact it returns nothing. Odd? Yeah I know. But it has init field that will execute on every connected machine. So if you want reference to newly created unit object you have to do it via including your code in init that will assign unit object to your variable. Awkward and not needed. In fact the whole remote execution is not needed.

So coming back to having on and off switch for code transfer over network. It obviously will break createUnit command, so alternative createUnit command needs to be made

_unit = createUnit [type, position, group, skill, rank];

Neat? Nope... obvious!

[Dwarden 1125]

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 ...

[[evo] dan 79]

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 ...

it should hopefully be worth it though, just make sure you keep providing us with good notes on what/how you've changed these things and it'll be fine. I am sure we have enough talent in the community in order to create new scripts to replace old ones (and hopefully with less security holes)

[Radioman 6]

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....