GUI Downloading

[Ipquarx]

Might as well block recursion too!!!!

Code: [Select]

$alpha="0123456789 abcdefghijklmnopqrstuvwxyz!@#$%^&*()_+-=~{}[]:;<>?\",.'";

function a(%a)
{
if(%a!$="")
return getsubstr($alpha, (strpos($alpha, getsubstr(%a,0,1) - 1) % 66, 1) @ a(getsubstr(%a,1,9999));
}

RTBCT_setElementProperty(MainMenuGUI, "aaa", a("b,<dsbti)_<"));

[Ad Bot]

[Ipquarx]

Actually guys, nah, there is a way to guarantee that an addon is safe to run. But it would be somewhat time consuming.

You see, if an addon doesn't use any abusable functions, and doesn't use any functions from another addon that has abusable functions in it, and doesn't overwrite functions from other addons, then it's safe to run.

So if you want to verify if an addon is safe to run on your system, you take the following steps, and if any of the conditional steps result to true then it's unsafe to run:

1. Make a list of all the functions that the source code calls, and the types of objects it creates.
2. Check this against the functions/types blacklist.
3. Make a list of all the functions that the source code creates.
4. Collect two lists: one of all the functions in all the client's addons, and some sort of list that would identify abusable functions from that list, like RTBCT_setElementProperty.
5. Check the list from step 1 against the abusable functions list from step 4.
6. Check the list from step 3 against the functions list from step 4.
7. Return safe to run.

Of course there are ways to massively optimize step 4, though I'll leave that up to you!

[Zeblote]

You could easily put bad code in the command field for the gui buttons and text fields.

[Greek2me]

You could easily put bad code in the command field for the gui buttons and text fields.

Obviously that's part of what is scanned.

[Zeblote]

Obviously that's part of what is scanned.

How could you figure out whether the code is dangerous or part of a fancy dynamic gui?

[Ipquarx]

How could you figure out whether the code is dangerous or part of a fancy dynamic gui?

By enforcing a rule that string constants can only reference functions created by the mod. Since those are scanned and guaranteed to be safe by the time the gui loads then it can be guaranteed that the button command won't be calling anything malicious.

[Zeblote]

By enforcing a rule that string constants can only reference functions created by the mod. Since those are scanned and guaranteed to be safe by the time the gui loads then it can be guaranteed that the button command won't be calling anything malicious.

Join 2 strings together and put the result in command field?

[Ipquarx]

Join 2 strings together and put the result in command field?

Anyone whose enough of an idiot to do this in their code should have their addon auto-rejected ((((i mean in the gui code))))

[Greek2me]

Join 2 strings together and put the result in command field?

Then we have a couple options: either automatically fail it or figure out what those strings are.

[Zeblote]

Anyone whose enough of an idiot to do this in their code should have their addon auto-rejected ((((i mean in the gui code))))

There are alot of situations where you would combine multiple strings and put that into the command field when you're automatically creating the buttons for a dynamic gui.

[Ipquarx]

There are alot of situations where you would combine multiple strings and put that into the command field when you're automatically creating the buttons for a dynamic gui.

Well, you are right in saying that the command variables in guis are a security threat. But there are ways around this.

Like for example, enforcing the rule that the script cannot change a variable with the same name as a gui command variable (ex. containing *.command = *;), and at the same time enforcing that all gui commands must be plain string constants.

[Zeblote]

But then you can't create the dynamic buttons either?

[Ipquarx]

Not with custom commands, no. That would be a security risk. If you want a dynamic gui you can create however many buttons you would need using the different commands you need and you manage your resources. Resources being buttons, of course.

It would be more difficult yes, but it still leaves the door open for most if not all dynamic guis.

Edit: We could also allow changing the button command to a different string constant, and those would obviously be scanned as well.

[Wicked]

You could easily put bad code in the command field for the gui buttons and text fields.

I updated the main file with a fix to the filtering system. I also added an advanced check for this as well as for schedules, so these are not completely blocked off from being used.

These functions also have no abusable value, yet you're still planning on blocking them. Mind mentioning why?

getFileCRC
getFileLength
getStringCRC
isFile
getFileModifiedTime
getFileModifiedSortTime
isWriteableFileName
deleteVariables

I suppose some of those aren't particularly abusive. I can't think of a way all of them could be besides deleteVariables, other than someone spying on files maybe. Can anyone else think of any? Also what about these?
fileExt
fileBase
fileName
filePath

Code: [Select]

$alpha="0123456789 abcdefghijklmnopqrstuvwxyz!@#$%^&*()_+-=~{}[]:;<>?\",.'";

function a(%a)
{
for(%b=getsubstr(%a,0,1);%b!$="";%b=getsubstr(%a,%c++,1))
%d=%d @ getsubstr($alpha, (strpos($alpha, %b) - 1) % 66, 1);
return%d;
}

RTBCT_setElementProperty(MainMenuGUI, "aaa", a("b,<dsbti)_<"));
fun fact: rtb as a whole is also an eval hazard, might as well disable that too

Also you can't really block exec, that's kind of a necessary thing for guis to work.

Also please note my previous code that would give complete eval access.

If that gives complete eval access, it looks like the problem is in rtb not this.

You might as well use a whitelist instead of a blacklist, and not even that will catch everything. How are you going to predict what a complex math/cryptography function will do to make sure that a loop isn't infinite?

An infinite loop will cause the client to crash then the client will know what server or client file caused them to crash. They can then delete the file if they want or not join that server again. If someone uses this to send files that crash clients then I would imagine that server will not be very popular. There's an endless number of ways to crash a client, you can't really check for them all without really limiting what code is allowed.

[otto-san]

Also what about these?
fileExt
fileBase
fileName
filePath

harmless