Deploying Standalones/Prevent Malicious Code

LiveCode is the premier environment for creating multi-platform solutions for all major operating systems - Windows, Mac OS X, Linux, the Web, Server environments and Mobile platforms. Brand new to LiveCode? Welcome!

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller

Post Reply
jsims
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 25
Joined: Thu Apr 30, 2009 1:45 pm
Contact:

Deploying Standalones/Prevent Malicious Code

Post by jsims » Mon Oct 05, 2009 5:09 pm

Hello All,

I've been thinking deployment strategies and I've come across a question I can't find an answer to.

The deployment method I'm leaning towards is multiple "Main" stacks where one is the executable and it uses the other (.rev) stacks. I believe this is similar to how RunRev deploys the IDE as I've noticed .rev files in, for example, the Toolset folder (such as revdatagridlibrary.rev). I'm attracted to this method because of the ability to more easily update "components" of the application.

So, I would have, for example, MyRevApp.exe and BaseControls.rev as my two files to deploy. Now, I know I can password protect stacks to keep people out of them, but what is to keep someone from creating some malicious code, naming the stack BaseControls.rev and dropping it into the folder my app is deployed in. When I "start using" BaseControls, the malicious code will be executed.

Is there a way to verify a stack is really my stack before I trigger any code in the stack?

Thanks in advance,
- John

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 10043
Joined: Sat Apr 08, 2006 7:05 am
Contact:

Post by FourthWorld » Mon Oct 05, 2009 5:21 pm

You might consider using a checksum on the stack files: read them into a variable and pass that into the md5Digest function, which will return a binary signature of the data. If you store that signature in your standalone and compare that to an MD5 value checked on startup you should have reasonable assurance that the stack file you're checking is indeed the one you originally put into place.

That said, such a method would preclude any dynamic updates in which you may want to replace individual components without replacing the standalone.

For such cases you might consider including a function in each of your stacks which returns a value known only to your standalone; you can call a function from a given object using the "call" command. If a stack returns a different value or doesn't include that function at all, you'll either get an unexpected value or an error, and either could serve as a flag to let you know to halt execution.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

jsims
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 25
Joined: Thu Apr 30, 2009 1:45 pm
Contact:

Post by jsims » Mon Oct 05, 2009 7:49 pm

Hi Richard,

Thanks for the reply.

I was thinking along the same lines of having the main executable "talk" to the stack prior to any code execution but I'm so new to Rev (and stack programming in general...I've always been an OO guy), I'm not sure of the order of events.

I've learned that to use the external stack, I use the "Start Using" command which sends the libraryStack message to the external stack. Is there a way to "inspect" or make some kind of call into the stack prior to the "Start Using" command?
- John

malte
Posts: 1098
Joined: Thu Feb 23, 2006 8:34 pm
Contact:

Post by malte » Mon Oct 05, 2009 8:10 pm

hi John,

before opening the stack you are loading dynamically you could

Code: Select all

lock messages
This will prevent to trigger any of the messages that are usually sent in the opening process of the stack. Then you could call the secret function as Richard mentioned in a try catch block. If that does not throw an error, unlock messages and start using the other stack, otherwise warn your user and quit the app.

All the best,
Malte

jsims
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 25
Joined: Thu Apr 30, 2009 1:45 pm
Contact:

Post by jsims » Tue Oct 06, 2009 2:35 pm

Hi Malte.

Excellent! That's just the kind of information I was looking for. So, to clarify, if I have legitimate code in my external stack's libraryStack handler, I could do the following:

1) Lock messages
2) Start using my external stack
3) Check my "secret function"
4) Assuming it is valid, Stop using my external stack
5) Unlock messages
6) Start using my external stack again (so it can now handle the libraryStack message)

OR...

Would I be just as well off after Step 3 to Unlock messages and then Send libraryStack to my external stack myself?

Thanks again for the information! Greatly appreciated!
- John

malte
Posts: 1098
Joined: Thu Feb 23, 2006 8:34 pm
Contact:

Post by malte » Tue Oct 06, 2009 9:33 pm

I would (in pseudo code)

lock messages
open invisible stack "yourLib"
try
call function
catch theErr
-- malicious reaction here
exit to top
end try
unlock messages
start using stack "yourLib"
-- move on, all fine

Hth,

Malte

jsims
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 25
Joined: Thu Apr 30, 2009 1:45 pm
Contact:

Post by jsims » Wed Oct 07, 2009 2:09 am

Thanks, Malte! I didn't know about "open invisible".
- John

Post Reply