definitely worth someone looking into -upvote

i'm curious...to clarify, with virtual ammo boxes, as i understand the data is stored as variables; are you suggesting one could potentially overwrite a variable and inject scripting? or just changing the variable for more loot?

or, that overwriting a mission's variable-stored scripting in profilenamespace? in this latter case i would suggest its not a vulnerability in the function, but bad coding practice on the scripters end...

@cancerouspete
VAS stores its data on the client side in profileNamespace. That's a no go for any MP mission. This data belongs on the server and nowhere else because one can easily overwrite profileNamespace data via the editor.

profileNamespace is fine as it is for storing simple client settings, it's not meant for storing important data which might influence MP missions.

When you save data it has a little prefix saying what data type it is. So for instance if you save a String, it will add a STRING prefix to your data.

So when a number is processed when loaded, it should be converted from a stored string to a number.
Same with an array. If the process of creating an array would be similar to the following example:
array = call compile "[1, 2, 3]";

Then you can change the "[1, 2, 3]" to something like
"Admin = getPlayerUID player; [1, 2, 3];"

I also found in my data a stored value containing this:
hint format["%1", getDammage player];

That could easily be changed to any desired script of the evil doer.

I suggest using this feature only server side to prevent players from injecting data that you don't want them to.

This actually does work. A friend of mine tried it out after this post just now. You can actually mess aboud and log on servers with other identities. This means you with Virtual ammobox can take someone else gear. Not to mention that if you are in Stratis life you have all that that person has. You can easly transfer vehicles and cars to yourself. then rejoin as your self and enjoy the profit.

It is up to mission makers to use profile namespace responsibly. You cannot inject unless you evaluate your profile namespace variable data. Why would one want to evaluate the variable data anyway? Granted stupidity has no limits but then you cannot hold hands of every mission maker.

Exactly. And yhea even if this is somthing to be fixed hackers find a new way annyway. Its just more a tip then an actually issue for mission makers to check everything trough.

What if you join a zombie server and it spams your file with random variables until it reaches 10GB in size?

Imposible. Server bandwith would be enormaus not to mention it cant spam you with virables. ALl you get is a cached version(playable) of the map on default. Everything else that gets put in(player location gear enc) is stored serverside. The only way for it to do that is on loding it would say receiving mission file 1 KB out of 10000000 KB.. wich yhea go figure no one is gna wait for that.

You let the script happen client side. 5kb mission. Player won't even noticed it downloaded.

nameSpace1 = profileNamespace;
while {true} do
{
call compile format["
nameSpace1 setVariable ['var%1%2','%3'];
", floor(random(10000000)), floor(random(10000000)), "SPAM"];
saveProfileNamespace;
};

wich yea go figure doesn't need you to wait to download it.

Okey true. But doing that (and i think you mean it sends package's of a xx size every now and then to stack the amount of space used on hdd). That could be possible. But by zombie server you mean server with mission that spams you with updates till the file is 10gb.. i dont see that happen. Since lag would be huge. Server has to send game updates to clients and received them at the same time. Whil doing it it must also send packages to players of certain size's and thats gona suck up some bandwith. Maybey we can test your idea by trying to make 1 mission file 500MB large and then stopping so we wont mess up annyones pc (Just 2 or 3 man test).

Ed, you are talking about malicious mission makers now. This makes no sense. As a mission maker you can probably do far worse things to your players than spamming profilenamespace. Why would you want to alienate your players? Surely you can just kill everyone on joining your server.

Yhea thats also somthing. You can pretty much do annything on arma since they DOwnload the mission from the Server. Go figure you can attach viruses to it since the scripting is .SQF and SQM.

I've tested this in my editor. It makes the file size go bigger by about 3kb per second. So imagine a hacker injecting this into a server using BIS_fnc_MP. You will play for about an hour on a server (or even more). Then your file will end at 3 x 60 x 60. Which is about 10mb. Not much. But imagine a hundred of these loops running in parallel.

Yes now imagine the lag. 20 players would mean 60KB's now imagine that times 100 6000KBS or 3MBS for just injecting people a hour with 6 MB of data. YOu can go as high as you want but at one point your bandwith be like F**k this and you lag. Not to mention the amount of calculations the game itself requires to do and other things people do like listen to music download a torrent. Its just impracticle to do this.

By using the following script, I made my file 100mb within a minute.

spammer = {
nameSpace1 = profileNamespace;
while {true} do
{
call compile format["
nameSpace1 setVariable ['var%1%2','%3'];
", floor(random(10000000)), floor(random(10000000)), "SPAM"];
};
};

while {true} do
{

• spawn spammer;

sleep 0.1;
saveProfileNamespace;
};

At least some kind of user defined limit should be added to prevent things like this.

Remember, this has nothing to do with the network connection. It's local only.

LOL you have to understand one thing about hackers, they want to see reaction to their hacks. Your hack provides no hacker satisfaction as most won't even notice it. Back to the drawing board I guess.

XD true. Also do you understand the meaning of bandwith? Like making these files is cool but they will never be good 1 hackers dont get profit from it and 2 your net wont sustain such bellend spam

I suggest this not turn into an argument. I have done my part in revealing a white hat.

@Killzone_Kid: You have no insight about this matter. It's not about satisfying any hacker. It's about preventing them from using this to cause mischief.

@Raoul1234: I don't know how writing a file and using bandwidth meets up. But if Wikipedia's meaning about bandwidth is wrong, then have my sincerest apologies.

*facepalm*
Hackers hack because they think its fun. The only reason for them to be fun if they can hear people rage or see theyre work is noticed.

Bandwith the amount of data you can send in a xx amount of time.

A hackers are not gona have fun since it takes hours to get results from this and hackers dont like that.

And the bandwith:
If you want this to be noticble you need to send allot of data in a xx amount of time.
ANd if your bandwith doesnt support that xx amount of data its not gona happen.

Do not only think in if its possible or not also think about the human nature behind this and the technical nature.
A: would people doing this get results from it soon enough for them to be pleased.
B: Would the time and money they spend in this worth the time it takes to get a small/medium/large result.
C: Is it reachable whitout having to spend to much time money on the resourches needed for this.

Today you can simply download simple tools to mess up peoples game play. Far more easyer then this and the results are instant.

BTW im not trying to turn this into an argument. Wer are just saying that even do this is doable the change of someone spending so much time and money into doing somthing that hardly impacts the player is slim.

If you want to prevent hacker from using it, stop hacker from unauthorised remote execution. If hacker can remote execute malicious script, your exploit is a drop in the ocean in comparison what they can do to remote user. What I'm saying no remote access no problem with profilenamespace. Remote access = big problem with everything. Sorry you have wasted your time trying to construct possible exploit, it is not that good.

You are correct. It's not good at all. That's why it needs attention.

There is no real solution to this.. Besides not storing scripts in profileNamespace.. Which is not that hard to do.