callExtension file search problem!

[killzone_kid 1327]

If you have -mod=@mod1;@mod2;

and "extention" callExtention ""

ArmA will look in

1. @mod2\extention.dll

2. @mod1\extension.dll

3. c:\extention.dll

4. ArmA 3\extention.dll

Shouldn't 3 and 4 be swapped around? First look in ArmA 3 dir then widen the search?

[Simas 12]

I think the 3) should be skipped altogether, no idea why would you look for an extension DLL in a C:\ drive. But it's not really an issue? I mean most likely you will ship your DLL with your addon anyway. Or did I miss the point?

By the way, I am also hacking a custom extension DLL right now. Had no idea you are doing the same :)

[killzone_kid 1327]

If I provide myext.dll in @myaddon

then I use "myext" callExtension "whatever" to get some data from extention that i then call compile

nothing stops someone else adding

-mod=@myaddon;@hackedaddon; to their client launch param

then placing hacked myext.dll in @hackedaddon folder on their client so that when "myext" callExtension "whatever" is executed @hackedaddon\myext.dll is executed. this works with standard server setup I checked.

one way of avoiding this is providing explicit path to dll and this is when it gets messy

---------- Post added at 13:09 ---------- Previous post was at 12:59 ----------

By the way, I am also hacking a custom extension DLL right now. Had no idea you are doing the same :)

I'm trying to properly release http://killzonekid.com/arma-regex-extensions-regex_match-dll-and-regex_replace-dll/ but ran into this problem which may affect security

[Simas 12]

Mhm, still do not see the issue. If someone wants to replace your DLL - nothing is stopping them (and you do not need a @hackedaddon for this, you can just go to the @myaddon folder and copy/replace stuff inside). Of course, since extension DLLs are not part of PBOs - they can't be signature-verified? But it's client side.. all they will be hacking is themselves. No one is going to replace your DLL on a Windows dedicated server.

[killzone_kid 1327]

Mhm, still do not see the issue. If someone wants to replace your DLL - nothing is stopping them (and you do not need a @hackedaddon for this, you can just go to the @myaddon folder and copy/replace stuff inside). Of course, since extension DLLs are not part of PBOs - they can't be signature-verified? But it's client side.. all they will be hacking is themselves. No one is going to replace your DLL on a Windows dedicated server.

That's where you're wrong. .dlls can be signed and verified (see the link). Once the hacker gained access to his own client scripts he can then cause havock for everyone else, it is just the open nature of arma

Edited June 4, 2013 by Killzone_Kid

[Simas 12]

I understand what you are saying. But imagine a situation where you have replaced that RegExp extension DLL with a hacked one (on your own PC). Who is going to hack who now? You can then use "myext" callExtension "something" to inflict damage to your own PC. I just don't see how this is a security issue.

[killzone_kid 1327]

I understand what you are saying. But imagine a situation where you have replaced that RegExp extension DLL with a hacked one (on your own PC). Who is going to hack who now? You can then use "myext" callExtension "something" to inflict damage to your own PC. I just don't see how this is a security issue.

Apart from once you have control over your client you can use any of the global commands on your client that will broadcast to every connected PC. If I run this piece of code on my client

{if (getPlayeUID _x != getPlayerUID player) then {_x setDamage 1}} forEach playableUnits;

it will kill every player on the server apart from me. How is this not a security problem?

[Simas 12]

It's a security risk if you blindly do a "call compile" on the data you get from extension. One solution is to not generate SQF with your C/C++ DLL - but rather use some sort of intermediate protocol (text based). Then the whole RegExp functionality would be exposed with SQF functions that use callExtension (and the accompanying protocol) internally only.

I just don't think this is something for BIS to deal with.

[killzone_kid 1327]

You cannot avoid to not to call compile. Extension returns string and only string. It is pointless to have RegEx functionality so that you can send one text string and receive another text string. Even a server side database extension sends a string formatted like array, the only way to retrieve it is to call compile.

The problem is not in call compiling the result the problem is with having explicit path to the extension. So far the only way of achieving it is to format the extension call like this:

"\@MyModFolder\myext" callExtension "params"

This will cause ArmA to freeze for a second but only initially. I suspect it is because it looks in every corner before finding extension. If I do

"@MyModFolder\myext" callExtension "params"

without starting slash, there is no freeze, and it indeed will find the extension in Arma 3\@MyModFolder UNLESS there is @MyModFolder\myext.dll on C drive

Then it will find that one. This is why it should look in Arma 3 folder first. You cannot have 2 identical mod folders in Arma 3 directory so there is no risk someone can spoof the path.

And once the correct file is found and used once it gets locked so you only need to do it once.

EDIT on second thought you can rename addon folders as you pleased, so this goes out of the window

Edited June 4, 2013 by Killzone_Kid

[Simas 12]

You cannot avoid to not to call compile. Extension returns string and only string. It is pointless to have RegEx functionality so that you can send one text string and receive another text string. Even a server side database extension sends a string formatted like array, the only way to retrieve it is to call compile.

I mentioned a text protocol for a reason. Instead of throwing SQF back from a DLL you could throw YAML - and use something like CBA_fnc_parseYAML to get the result back. No security risks involved whatsoever and no "call compile" required.

You could probably even use something more simpler and faster for data serialization (I just used YAML as a quick example).

The problem is not in call compiling the result the problem is with having explicit path to the extension.

(snip)

And once the correct file is found and used once it gets locked so you only need to do it once.

Yeah, I just ran a quick test and was able to reproduce the issue. To be honest - I think the C: (I assume it's rather the drive where Arma is installed) should be skipped entirely. I suspect it was done simply to ease with the development or something.

Have you submitted a feedback bug report?

[killzone_kid 1327]

I want to avoid using CBA. It is like with Javascript and jQuery loading the whole wagon of functions so you can only use one. No thanks. Also at some point I guess even CBA need to call compile, there is no other way, there is no magic function in SQF that goes oh look, this looks like array so lets treat it like one. If they use native sqf to parse YAML it will be slow. Also the whole thing about Regex it is lightning fast, if I start converting and unconverting results and what not might as well not bother.

One solution I currently explore is

equalModRequired = 1;

think this could be the only way

Have you submitted a feedback bug report?

Not sure this is a bug

---------- Post added at 20:31 ---------- Previous post was at 19:18 ----------

OK equalModRequired = 1; doesn't work on Arma 3 server

[killzone_kid 1327]

It gets worse. I can verify signature of signed .dll no problem, however if it is on the client the public key need to exist in Keys folder on the client too. Even I enable verifySignatures = 2; server refuses to check signatures on signed .dlls or to even complain that I have unsigned files in addons folder among other .pbos.