Is tengo safe for external scripts?

d5 / tengo

A fast script language for Go

https://tengolang.com

MIT License

3.52k stars 303 forks source link

Is tengo safe for external scripts? #319

Open pedrolvr opened 3 years ago

pedrolvr commented 3 years ago

I need to execute the possibly untrusted scripts sent by users and I would like knowing if Tengo could be used for that.

geseq commented 3 years ago

If they’re untrusted and you aren’t running tengo in some sort of secured sandbox, I wouldn’t recommend it (not just with tengo mind you, but with any language)

d5 commented 3 years ago

Hard to guarantee anything without knowing what kind of untrusted code you want to run, but, Tengo is "relatively" more secure because the script is compiled into bytecode and run in a VM (whereas other runtime interpreter might expose more vulnerabilities). Also you can control which packages you want to allow for the user script. And, there's no easy way to set the maximum memory usage, but, you can set the maximum number of objects the user script can create instead.

pedrolvr commented 3 years ago

Thanks guys for the answers. The feature is to run code from users like Salesforce after record events, such as save/update/delete/checkout/... One way to add triggers.

d5 commented 3 years ago

If you're going to write your own packages (to interact with external services for example), I think Tengo is fairly safe to run the user code. See https://github.com/d5/tengo/blob/master/docs/interoperability.md#sandbox-environments.

pedrolvr commented 3 years ago

Great! I understood that I can create a minimum environment for the user with controlled functions to access external or internal (db queries by id, ...) resources in a safe way.

ozanh commented 3 years ago

Hi @phenrigomes , I'd like to add a few of my experiences. I hope it helps.

Always run with context having a timeout.
Do good cleanup, there is no exception handler.
Do not share your compiled scripts between gorouties.
Check built-in module implementations if you expose them, e.g. do not give access to os or times.sleep().
Do not rely on allocation limits as mentioned before, e.g. copy built-in function can easily exceeds the limits in a loop.
Security related bugs may be shared before a release, add watch to Tengo github account and keep your library up to date.
Do not hesitate to ask for help.
Be ready for sql injection if you give access to db operations or building sql strings.

d5 commented 3 years ago

Do not rely on allocation limits as mentioned before, e.g. copy built-in function can easily exceeds the limits in a loop.

Haha. That's a good one.

There's no easy way to control/limit memory allocations in Go in general.

siff-duke commented 3 years ago

It would be good if time.sleep() is in in the os module. I'm not importing the os module but need the times module for parsing and time calcs.

niemeyer commented 2 years ago

Hello all. Arriving a bit late, but thanks for the interesting discussion here.

Was there ever a discussion about solving the case of copy? Maybe an argument or extra return parameter that helps accounting for the changes performed? It might actually be a nice general idea to allow extension functions to collaborate with the accounting, so it becomes a bit more realistic.

Also, is there any other known case of stronger deviations on the allocation accounting?